Automatically generate variables
Nate
I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this, but I had something
like this in mind...
int i;
for(i = 1; i < 4; i++){
int variable....
}
For example, this loop would declare the following variables all of
type int:
variable1
variable2
variable3
Is something like this possible? Is there another way?
Thanks in advance,
-Nate
Marc Boyer
> Is something like this possible? Is there another way?
An array ?
Marc Boyer
Christopher Benson-Manica
> I am looking for a method to automatically declare variables in C.
> I'm not sure if there is a good way to do this, but I had something
> like this in mind...
No, theres no "good" way. Your way, in particular, is wrong. C
doesn't work like that.
> int i;
> for(i = 1; i < 4; i++){
> int variable....
> }
> Is something like this possible? Is there another way?
Yes; there's a bad (IMHO) way:
#define DECLARE1(type,var) type var##1
#define DECLARE2(type,var) DECLARE1(type,var); \
type var##2
#define DECLARE3(type,var) DECLARE2(type,var); \
type var##3
int main( void ) {
DECLARE3(int,foo);
return 0;
}
You could generate as many #defines as you please using some other
program (say a shell script) and put them in a separate header file.
Alternatively, you could tell us what you *really* want to do and we
can probably suggest a much better alternative.
--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Joe Estock
> Nate <nver...@sbcglobal.net> wrote:
>
>> I am looking for a method to automatically declare variables in C.
>> I'm not sure if there is a good way to do this, but I had something
>> like this in mind...
>
> No, theres no "good" way. Your way, in particular, is wrong. C
> doesn't work like that.
>
>> int i;
>
>> for(i = 1; i < 4; i++){
>> int variable....
>> }
>
>> Is something like this possible? Is there another way?
>
> Yes; there's a bad (IMHO) way:
>
> #define DECLARE1(type,var) type var##1
> #define DECLARE2(type,var) DECLARE1(type,var); \
> type var##2
> #define DECLARE3(type,var) DECLARE2(type,var); \
> type var##3
Or the [slightly] more maintainable way:
#define DECLARE(var, seq) var##seq
>
> int main( void ) {
> DECLARE3(int,foo);
> return 0;
> }
int main(void)
{
int DECLARE(foo, 1);
int DECLARE(foo, 2);
DECLARE(foo, 1) = 10;
foo2 = 5;
printf("foo1: %d foo2: %d\n", DECLARE(foo, 1), foo2);
return(0);
Christopher Benson-Manica
> Or the [slightly] more maintainable way:
> #define DECLARE(var, seq) var##seq
> int main(void)
> {
> int DECLARE(foo, 1);
> int DECLARE(foo, 2);
It's more maintainable, yes, but it also rather defeats the purpose of
the whole exercise, doesn't it? If one wants int foo1 through int
foo100, what's the added benefit of invoking the macro 100 times as
opposed to simply writing the actual declarations?
Mark McIntyre
<nver...@sbcglobal.net> wrote:
>Hello,
>
>I am looking for a method to automatically declare variables in C.
>I'm not sure if there is a good way to do this,
There isn't - you can't define object names at runtime in C.
You could mallocate an array of objects however, and size it to
whatever size you needed. This is likely to be more useful anyway as
the chances are you will need to loop over the variables.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
jacob navia
#include <stdio.h>
int main(void)
{
FILE *f = fopen("variables.c","w");
for (int i=0; i<100; i++) {
fprintf(f,"int variable%d\n",i);
}
fclose(f);
}
Kenny McCormack
You need to finish what you started. IOW, you forgot to mention:
1) And then compile variables.c as a shared library
2) And then dlopen that library
3) And then enjoy your new symbols
All OT, blah, blah, blah, of course.
jacob navia
> On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
> <nver...@sbcglobal.net> wrote:
>
>
>>Hello,
>>
>>I am looking for a method to automatically declare variables in C.
>>I'm not sure if there is a good way to do this,
>
>
> There isn't - you can't define object names at runtime in C.
>
Wrong
#include <stdio.h>
#include <windows.h>
int main(void)
{
FILE *f = fopen("dynamic.c","w");
void (*fn)(void);
void *ptr;
// 1 Define some structure for instance
fprintf(f,"struct dynamicobject { char *name;int len; };\n");
// 2 Define an object of that type
fprintf(f,"struct dynamicobject var = {\"NoName\",6};\n");
// 3 Define an exported function in a shared object that returns the
// address of the created object
fprintf(f,"void * __declspec(dllexport) \n");
fprintf("GetDynamicObject(void)\n\treturn &var;}\n");
// Done Close the file
fclose(f);
// Compile it. The compiler can change of course :-)
system("lcc dynamic.c");
// Link it into a shared object
system("lcclnk -dll dynamic.obj");
// Open the shared object (dlopen under Unix)
void *h = LoadLibrary("variables.dll");
// Get the address of the created function in the shared object
fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
// Call the function we just compile
ptr = fn();
// And now, ladies and gentlemen
// Here I have a pointer to a dynamically created object
}
Most of my customers buy lcc-win32 as a "Just in time compiler", that
allows them to do this much more efficiently than what is shown here
A JIT compiler is specialized in generating code dynamically. For
instance, if you are modelling molecule interaction you can develop
a special language that is task oriented, compile it to C, then
just JIT compile it into a shared object that you run on the fly.
Of course what you generate is an object, not NAMES...
In this sense the OP is completely wrong of course.
jacob navia
Joe Estock
> Joe Estock <jes...@nospamnutextonline.com> wrote:
>
>> Or the [slightly] more maintainable way:
>
>> #define DECLARE(var, seq) var##seq
>
>> int main(void)
>> {
>> int DECLARE(foo, 1);
>> int DECLARE(foo, 2);
>
> It's more maintainable, yes, but it also rather defeats the purpose of
> the whole exercise, doesn't it? If one wants int foo1 through int
> foo100, what's the added benefit of invoking the macro 100 times as
> opposed to simply writing the actual declarations?
>
Personally I would use an array of type int; I was merely condensing
your example and I missed the very important part of functionality that
was originally sought. After reviewing your original code I see that it
defeats the original intent of declaring several variables at once. I
was distracted by the vast amount of snow outside when I replied to your
original thread.
Flash Gordon
> Mark McIntyre wrote:
>> On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
>> <nver...@sbcglobal.net> wrote:
>>
>>> Hello,
>>>
>>> I am looking for a method to automatically declare variables in C.
>>> I'm not sure if there is a good way to do this,
>>
>> There isn't - you can't define object names at runtime in C.
>
> Wrong
No, he is correct.
> #include <stdio.h>
> #include <windows.h>
> int main(void)
> {
> FILE *f = fopen("dynamic.c","w");
> void (*fn)(void);
> void *ptr;
>
> // 1 Define some structure for instance
> fprintf(f,"struct dynamicobject { char *name;int len; };\n");
> // 2 Define an object of that type
> fprintf(f,"struct dynamicobject var = {\"NoName\",6};\n");
> // 3 Define an exported function in a shared object that returns the
> // address of the created object
> fprintf(f,"void * __declspec(dllexport) \n");
The above line would prevent the C file that is being written from
compiling on most C compilers.
> fprintf("GetDynamicObject(void)\n\treturn &var;}\n");
> // Done Close the file
> fclose(f);
> // Compile it. The compiler can change of course :-)
> system("lcc dynamic.c");
Here you are using something called a "C compiler". Strangely enough it
is not actually part of C instead it is a tool used to operate on C
sources. On some systems there will not be a C compiler installed and
the user might not have permissions to install one.
> // Link it into a shared object
> system("lcclnk -dll dynamic.obj");
Here you are using something called a linker which is also not part of C.
> // Open the shared object (dlopen under Unix)
> void *h = LoadLibrary("variables.dll");
Here you are suggesting using functions that are not part of C that are
not available on all implementations. Oh, and you security systems that
prevent untrusted programs from doing untrusted things like loding
shared objects from untrusted places (i.e. anywhere the user can write to).
> // Get the address of the created function in the shared object
> fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
So you are casting something to a function pointer type different from
the definition of the function pointer you are assigning it to. I would
suggest you read the manuals for the compiler you are using to find out
how to enable a sensible level of warnings, but seeing as it is your
compiler I can't imagine why they would not be set already.
> // Call the function we just compile
> ptr = fn();
Now you are expecting to get a return value from a function that you
have told the compiler does not return anything. Did you compiler not
generate an error here? I know the standard would allow a warning, but
an error would be more appropriate.
> // And now, ladies and gentlemen
> // Here I have a pointer to a dynamically created object
> }
>
> Most of my customers buy lcc-win32 as a "Just in time compiler", that
> allows them to do this much more efficiently than what is shown here
Well, I hope you give them something a little closer to being a C
compiler than the above code was to being C.
> A JIT compiler is specialized in generating code dynamically. For
> instance, if you are modelling molecule interaction you can develop
> a special language that is task oriented, compile it to C, then
> just JIT compile it into a shared object that you run on the fly.
Now, had you suggested the OP embed some kind of scripting language with
or without a JIT that might have been more sensible. Instead you try to
suggest that using tools at run time that are not installed on most
systems is part of C.
> Of course what you generate is an object, not NAMES...
> In this sense the OP is completely wrong of course.
The OP is completely wrong to look for a solution to his/her problem or
completely wrong for not being sure if it exists?
There is no mechanism provided in C to do what the OP asked. On *some*
systems you can use things outside of the C language to do the sort of
thing you are suggesting. However you are going so far that you might as
well say that the ability to run Windows Vista is part of C.
--
Flash Gordon
Christopher Benson-Manica
(WRT int foo1 ... int foo100)
> Personally I would use an array of type int;
Well, me too, and there probably isn't a great reason for OP not to as
well. There certainly aren't a lot of alternatives, and none that are
good.
> I
> was distracted by the vast amount of snow outside when I replied to your
> original thread.
Posting to comp.lang.c would certainly seem to beat shoveling it :-)
Eric Sosman
"variables.c", line 2: undefined or not a type: variable0
"variables.c", line 3: parameter not in identifier list: variable1
"variables.c", line 3: syntax error before or at: int
"variables.c", line 4: parameter not in identifier list: variable2
[...]
"variables.c", line 99: syntax error before or at: int
"variables.c", line 100: parameter not in identifier list: variable98
"variables.c", line 101: parameter not in identifier list: variable99
"variables.c", line 101: syntax error before or at: <EOF>
cc: acomp failed for variables.c
One hundred fifty-one diagnostics all told. An impressive
yield for an investment of a mere nine lines of code.
jacob navia
Add a semi colon at the end of the line.
Old Wolf
> For example, this loop would declare the following variables all of
> type int:
>
> variable1
> variable2
> variable3
>
> Is something like this possible? Is there another way?
int variable[4];
Then access them like this:
variable[0] = 4;
variable[1] = 3;
...
variable[3] = 10;
The numbers will be 0 through to one less than the parameter
you specified in the declaration.
If you don't know how many you will need until runtime
then you can write:
int *variable = malloc( 4 * sizeof *variable );
and then access them in the same way as before.
Nate
OW,
This solution will work perfectly for what I'm trying to do, thank you
for your suggestion.
In fact, I will know the size needed for the array each time so it
will make the solution that much easier to implement.
Thanks again,
-Nate
santosh
> On Feb 14, 5:02 pm, "Old Wolf" <oldw...@inspire.net.nz> wrote:
> > On Feb 14, 5:35 am, "Nate" <nverb...@sbcglobal.net> wrote:
> >
> > > For example, this loop would declare the following variables all of
> > > type int:
> >
> > > variable1
> > > variable2
> > > variable3
> >
> > > Is something like this possible? Is there another way?
> >
> > int variable[4];
> >
> > Then access them like this:
> >
> > variable[0] = 4;
> > variable[1] = 3;
> > ...
> > variable[3] = 10;
> OW,
>
> This solution will work perfectly for what I'm trying to do, thank you
> for your suggestion.
You could've said you wanted arrays. Your C text should have atleast a
chapter on it.
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>Mark McIntyre wrote:
>> On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
>> <nver...@sbcglobal.net> wrote:
>>
>>
>>>Hello,
>>>
>>>I am looking for a method to automatically declare variables in C.
>>>I'm not sure if there is a good way to do this,
>>
>>
>> There isn't - you can't define object names at runtime in C.
>>
>
>
>Wrong
Right.
>#include <stdio.h>
>#include <windows.h>
Beep beep. This isn't C.
> void *h = LoadLibrary("variables.dll");
> fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
This isn't either.
But then you knew this, you just wanted to disagree with me I suspect.
Yevgen Muntyan
> On Wed, 14 Feb 2007 00:25:45 +0100, in comp.lang.c , jacob navia
> <ja...@jacob.remcomp.fr> wrote:
>
>> Mark McIntyre wrote:
>>> On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
>>> <nver...@sbcglobal.net> wrote:
>>>
>>>
>>>> Hello,
>>>>
>>>> I am looking for a method to automatically declare variables in C.
>>>> I'm not sure if there is a good way to do this,
>>>
>>> There isn't - you can't define object names at runtime in C.
>>>
>>
>> Wrong
>
> Right.
Agreed.
>> #include <stdio.h>
>> #include <windows.h>
>
> Beep beep. This isn't C.
>
>> void *h = LoadLibrary("variables.dll");
>> fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
>
> This isn't either.
Nonsense. It is C. It's not strictly conforming, it won't work
almost anywhere, it's rather useless, it's off-topic here, all this
was in details explained in another reply to JN post. But it is C,
where "C" means "C language as defined by the ISO standard".
Yevgen
santosh
> Mark McIntyre wrote:
> > jacob navia wrote:
> >> Mark McIntyre wrote:
<snip>
> >>> There isn't - you can't define object names at runtime in C.
> >>
> >> Wrong
> >>
> >> #include <stdio.h>
> >> #include <windows.h>
> >
> > Beep beep. This isn't C.
> >
> >> void *h = LoadLibrary("variables.dll");
> >> fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
> >
> > This isn't either.
>
> Nonsense. It is C. It's not strictly conforming, it won't work
> almost anywhere, it's rather useless, it's off-topic here, all this
> was in details explained in another reply to JN post. But it is C,
> where "C" means "C language as defined by the ISO standard".
But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard. If one or more of these extensions change the
standard syntax and semantics of C, then it's debatable if the
resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.
jacob navia
This means that there is no single serious program besides hello world
ones that is written in C.
OK?
Neither the linux kernel, nor all the network programs, nor any GUI
program, nor any library that uses graphics, networking, threads,
exception handling, nor the dynamic loader, nor any program that uses
a directory structure (file directories aren't defined in standard
C) nor all the embedded systems that use myriads of extensions
adapted to each circuit board, etc.
There are then NO PROGRAMS WRITTEN IN C.
Satisfied?
Yevgen Muntyan
> Yevgen Muntyan wrote:
>> Mark McIntyre wrote:
>>> jacob navia wrote:
>>>> Mark McIntyre wrote:
>
> <snip>
>
>>>>> There isn't - you can't define object names at runtime in C.
>>>> Wrong
>>>>
>>>> #include <stdio.h>
>>>> #include <windows.h>
>>> Beep beep. This isn't C.
>>>
>>>> void *h = LoadLibrary("variables.dll");
>>>> fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
>>> This isn't either.
>> Nonsense. It is C. It's not strictly conforming, it won't work
>> almost anywhere, it's rather useless, it's off-topic here, all this
>> was in details explained in another reply to JN post. But it is C,
>> where "C" means "C language as defined by the ISO standard".
>
> But the ISO standard doesn't define the windows.h header or the
> functions LoadLibrary or GetProcAddress. It uses the syntax and
> semantics as defined in the standard, but uses various extensions not
> defined in the standard.
This is true, but we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
is what I call nonsense, simply because it's too restrictive - if
one accepts such definition of a "C program", then all those C
programmers out there are writing programs in some fancy language
which is not C, and all those C programs out there are not C
programs. Then, I think the standard exists to make people able
to write C programs using extensions. And it uses term "strictly
conforming" exactly to distinguish programs which are completely
described and programs which use extensions but are still C programs,
but to not restrict itself only to those strictly conforming
programs. The syntax and semantics of "a C program" have very big
value, what would be the point of having the standard which simply
stops working as soon as non-standard header is used?
I personally don't have that wider definition, and I don't think
anyone could come up with something sensible here. And it's the
reason why *on-topic* here are only strictly conforming programs.
But there is more to C than programs using only standard features.
For instance, a C program which uses POSIX regex to work with
some strings, or a program which uses windows API to print list of
processes, are C programs as long as they don't use some fancy
non-C syntax or mechanics (insert "semantics" here).
> If one or more of these extensions change the
> standard syntax and semantics of C, then it's debatable if the
> resulting code can even be called as C. That's why GNU C is called as
> GNU C and not C.
I'd say "GNU C" is the same nonsense as "C/C++". There is one C
language, and there are extensions to it; "C with GNU extensions" sounds
better here. If you need gcc to compile a program, then it's not
a "C program as defined by the C standard", it's a program written
in GCC dialect of C or whatever you call it. But if any working
(QoI thing here) compiler on given platform (one more non-standard
thing, you got to accept that <windows.h> is only for windows) can
compile it without any fancy compatibility switches, then it's C. It's
just an empiric test of course, without 100% success guarantee. But
then, one can't prove that given program of reasonable complexity is
strictly-conforming either (I guess one could say he can get all
conforming implementations in the world and simply check, according
to the definition, I'd love to see that).
Anyway, answer to "C or not C" certainly should not involve sympathy or
antipathy to Jacob Navia. Saying "beep beep not C hahaha because I don't
like you" is total nonsense. Off-topic, sure. But C. If one says
that silly JN's program isn't C, he says that the great deal of C
programs (like all the C programs which work on your computer, except
maybe one) suddenly stop being C programs. And that's nonsense.
And it's not only about JN's program of course, elsewhere people already
told that C means in comp.lang.c something different than in the
rest of the world.
Yevgen
Flash Gordon
> santosh a écrit :
<snip>
>> resulting code can even be called as C. That's why GNU C is called as
>> GNU C and not C.
>>
>
> This means that there is no single serious program besides hello world
> ones that is written in C.
>
> OK?
>
> Neither the linux kernel, nor all the network programs, nor any GUI
> program, nor any library that uses graphics, networking, threads,
> exception handling, nor the dynamic loader, nor any program that uses
> a directory structure (file directories aren't defined in standard
> C) nor all the embedded systems that use myriads of extensions
> adapted to each circuit board, etc.
>
> There are then NO PROGRAMS WRITTEN IN C.
>
> Satisfied?
You've posted this before when people have pointed out that some things
are not C but extensions. The answer is still the same that some
programs can be written completely in standard C and vast amount more
can have 95% written in standard C with the remaining 5% nicely isolated
and written in whatever system specific method is appropriate.
--
Flash Gordon
Yevgen Muntyan
Looks like there are two ways to apply C standard in real life. One is
to call C programs (not necessarily strictly conforming) C programs;
another one is to claim that something *can* be done in some way. Note
that the standard doesn't know what it means 95% is C and 5% isn't.
You pollute your program with "1%" of non-C and it stops being C,
the whole thing is no longer a C program (namely what you call a C
program). And it's certainly true that vast majority of real C programs
installed on computers are not written that way, 95% here and 5%
isolated there. Jacob isn't right here of course, there are strictly
conforming C programs, sure. But his statement (the conditional one,
the "if that's not C then there are no C programs") is far closer
to reality and truth than your "answer", that "vast amount more *can*
have .." (emphasis mine).
I do agree that Jacob is one of persons who make it harder to talk
about real life C applications here, but if one wants to shut him up,
he can choose lot of other things, without the need to make this
newsgroup like bunch of jerks who pretend real programs are not what
they actually are.
Yevgen
santosh
> santosh wrote:
> > Yevgen Muntyan wrote:
> >> Mark McIntyre wrote:
> >>> jacob navia wrote:
> >>>> Mark McIntyre wrote:
<snip>
> >>>> #include <stdio.h>
> >>>> #include <windows.h>
> >>> Beep beep. This isn't C.
<snip>
> >> Nonsense. It is C. It's not strictly conforming, it won't work
> >> almost anywhere, it's rather useless, it's off-topic here, all this
> >> was in details explained in another reply to JN post. But it is C,
> >> where "C" means "C language as defined by the ISO standard".
> >
> > But the ISO standard doesn't define the windows.h header or the
> > functions LoadLibrary or GetProcAddress. It uses the syntax and
> > semantics as defined in the standard, but uses various extensions not
> > defined in the standard.
>
> This is true, but we have a choice here: call a "C program" only
> strictly conforming programs or use a wider definition. The former
> is what I call nonsense, simply because it's too restrictive - if
> one accepts such definition of a "C program", then all those C
> programmers out there are writing programs in some fancy language
> which is not C, and all those C programs out there are not C
> programs. Then, I think the standard exists to make people able
> to write C programs using extensions. And it uses term "strictly
> conforming" exactly to distinguish programs which are completely
> described and programs which use extensions but are still C programs,
> but to not restrict itself only to those strictly conforming
> programs. The syntax and semantics of "a C program" have very big
> value, what would be the point of having the standard which simply
> stops working as soon as non-standard header is used?
<rest snipped>
I can see your reasoning.
The imaginary boundary which divides a peice of code from being
reasonably called as C from being in a C-like language is undefined
and blurred. The standard fully defines conforming C programs. In
addition it allows implementation specific decisions for various
aspects and extensions as well. Certainly the code posted by jacob
navia qualifies as C code. The issue is what we exactly mean by term C
code. If we mean "the language as defined by the C standard", (which
is what you wrote earlier), then does his code snippet qualify as C
code? I think so.
But what about more fundamental extensions like the && gcc extension
discussed in another thread or the various operator overloading
features implemented by the lcc-win32 compiler? Can code that use such
"radical" extensions still be called as C? I don't think so. What
makes one extension reasonable and another not, from the POV of being
compatible with C?
Unless we take the strict approach of adhering to what the standard
specifies and allows, we seem to get into a lot of "gray areas" about
what is, and is not, C. It seems to ultimately come down to personal
opinion, something I'm not happy about.
Richard Heathfield
<snip>
> The imaginary boundary
...is not imaginary, and is not a boundary.
> which divides a peice of code from being
> reasonably called as C from being in a C-like language is undefined
> and blurred.
Yes, it's more like a beard than a boundary. Does a man with one hair on
his chin have a beard? Clearly not. Does a man with ten thousand hairs
on his chin have a beard? Yes, and to spare! So where is the dividing
line? If we say a man with N hairs on his chin has no beard, but a man
with N + 1 hairs /does/ have a beard, people would rightly laugh. And
yet some men have beards, and others don't.
> The standard fully defines conforming C programs.
Perhaps, but not their behaviour. It only says that a conforming C
program is one that is acceptable to a conforming implementation.
<snip>
> Unless we take the strict approach of adhering to what the standard
> specifies and allows, we seem to get into a lot of "gray areas" about
> what is, and is not, C. It seems to ultimately come down to personal
> opinion, something I'm not happy about.
Yes, the concept of "strictly conforming" is too strong to be useful,
and the concept of "conforming" too weak. In this newsgroup, the
concept of "comp.lang.c-conforming" has proved itself to be far more
effective.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
jacob navia
> I do agree that Jacob is one of persons who make it harder to talk
> about real life C applications here, but if one wants to shut him up,
> he can choose lot of other things, without the need to make this
> newsgroup like bunch of jerks who pretend real programs are not what
> they actually are.
>
> Yevgen
Look Yevgen, I can't parse that sentence. Maybe shorter sentences would do.
What I wanted to demonstrate with my snippet is basically:
1) You can use a C program to generate a C source file.
2) You can use the C compiler to compile it
3) You can use the dynamic loader to load it into memory
4) You can get a function pointer from the loaded file
and execute it.
This is possible in a wide variety of systems, from Unix, to
Windows, to many embedded systems. It is called a JIT, a
Just In Time compiler. Obviously how do you implement those
steps is system specific, and will change slightly from
system to system.
Instead of going into the question at hand (generating C
programs dynamically) we delve into boring stuff about
this being C or not. This is ridiculous and hinders any
discussion about real programs.
jacob
P.S. I do see the danger of discussiong very system specific
stuff, but the OTHER danger, not discussing anything at all but
the restricted subset of C proposed by some people here is even
worst!
Ian Collins
>
> But what about more fundamental extensions like the && gcc extension
> discussed in another thread or the various operator overloading
> features implemented by the lcc-win32 compiler? Can code that use such
> "radical" extensions still be called as C? I don't think so. What
> makes one extension reasonable and another not, from the POV of being
> compatible with C?
>
&& gcc extension and operator overloading) and platform specific
libraries. It is a fairly straightforward exercise for a developer to
implement a set of functions defined in a library (say Posix file
handling or BSD style sockets), but not to implement extensions to the
language. Which makes the former portable and the latter not.
Anything which conforms to the language defined in the current C
standard is a C program, which includes programs that include
non-standard headers.
--
Ian Collins.
Yevgen Muntyan
No it doesn't, it fully defines strictly conforming programs,
the ones which in particular do not contain code like
#include "foo.h"
"Just" conforming is no good, C++ programs seem to be conforming
because gcc accepts them, and gcc is a conforming implementation
(GNU compiler collection, that is, not the binary called 'gcc').
> In
> addition it allows implementation specific decisions for various
> aspects and extensions as well. Certainly the code posted by jacob
> navia qualifies as C code. The issue is what we exactly mean by term C
> code. If we mean "the language as defined by the C standard", (which
> is what you wrote earlier), then does his code snippet qualify as C
> code? I think so.
Yes, I do think so too.
> But what about more fundamental extensions like the && gcc extension
> discussed in another thread or the various operator overloading
> features implemented by the lcc-win32 compiler? Can code that use such
> "radical" extensions still be called as C? I don't think so.
I agree here too.
> What
> makes one extension reasonable and another not, from the POV of being
> compatible with C?
And I don't know the answer for this. And as I said, I don't think
one can provide sensible answer which would not involve what one
feels as opposed to what exactly is said in some definition.
> Unless we take the strict approach of adhering to what the standard
> specifies and allows, we seem to get into a lot of "gray areas" about
> what is, and is not, C. It seems to ultimately come down to personal
> opinion,
True. But it's not bad. It seems to me people generally agree on
what's C and what's not C (unless it's an argument in comp.lang.c).
And that's what really matters.
> something I'm not happy about.
Sure, it would be easier if the standard said "this is C, and the
rest isn't C and I don't care about that", but then the standard
would be useless. So we have what we have. I believe it's called
"trade off" in English.
Yevgen
Keith Thompson
[...]
> What I wanted to demonstrate with my snippet is basically:
> 1) You can use a C program to generate a C source file.
Agreed. Strictly speaking, I'm not sure that the specification for
what must be accepted as a C source file necessarily exactly matches
the representation of a text file generated by stdio calls, but I'll
ignore that; if nothing else, a format translation should be
straightforward. (This isn't entirely theoretical; consider a
cross-compiler where the host and target systems have different text
file representations.)
> 2) You can use the C compiler to compile it
Sure, if you have a C compiler. Not all systems do.
> 3) You can use the dynamic loader to load it into memory
That's extremely system-specific.
> 4) You can get a function pointer from the loaded file
> and execute it.
Likewise, that's extremely system-specific.
The solution you propose is so system-specific as to be unworkable in
general. Consider MS Windows systems, for example. There are several
free C implementations for MS windows, and several for which you have
to pay money. There is no one compiler that you can assume will exist
on any particular system. If you distributed a Windows program that
depended for its operation on the mechanism you describe, there would
be no way to make it work in general (unless you distribute a C
compiler along with it). And that's just one operating system; a
general solution is quite impossible (short of a huge nest of
#ifdef's).
> This is possible in a wide variety of systems, from Unix, to
> Windows, to many embedded systems. It is called a JIT, a
> Just In Time compiler. Obviously how do you implement those
> steps is system specific, and will change slightly from
> system to system.
How many embedded systems have C compilers available *on the target
system*? And I don't believe that the implementation wil change
"slightly" from system to system; there is no standard for this kind
of thing.
I'm not aware of anyone who's actually implemented what you suggest
even in a manner that will work on both Unix and Windows, systems
which are far more similar to each other than a number of other
systems out there.
And, as I recall, the solution you proposed, even assuming it can be
made to work, wasn't even appropriate to the OP's problem. All he
really needed was an array.
[snip]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Flash Gordon
> Yevgen Muntyan a écrit :
>> I do agree that Jacob is one of persons who make it harder to talk
>> about real life C applications here, but if one wants to shut him up,
>> he can choose lot of other things, without the need to make this
>> newsgroup like bunch of jerks who pretend real programs are not what
>> they actually are.
>>
>> Yevgen
>
> Look Yevgen, I can't parse that sentence. Maybe shorter sentences would do.
>
> What I wanted to demonstrate with my snippet is basically:
> 1) You can use a C program to generate a C source file.
Yes.
> 2) You can use the C compiler to compile it
What makes you think a C compiler is installed on the majority of systems?
> 3) You can use the dynamic loader to load it into memory
What makes you think a dynamic loader is part of C?
> 4) You can get a function pointer from the loaded file
> and execute it.
This also is not part of standard C.
> This is possible in a wide variety of systems, from Unix, to
Not if the compiler is not installed.
> Windows,
Windows does not have a compiler installed by default and probably most
Windows systems do not have one.
> to many embedded systems.
I've yet to use or develop for an embedded system that came with a C
compiler installed on it. For a start the compilers for most embedded
systems are build to run on completely different hardware.
> It is called a JIT, a
> Just In Time compiler. Obviously how do you implement those
> steps is system specific, and will change slightly from
> system to system.
So you provide a solution where only the most trivial step is C and the
rest is system specific and would require installing additional software
on the target system (that may not be available for it) and call it a C
solution?
> Instead of going into the question at hand (generating C
> programs dynamically) we delve into boring stuff about
> this being C or not. This is ridiculous and hinders any
> discussion about real programs.
It is not C.
> jacob
>
> P.S. I do see the danger of discussiong very system specific
> stuff,
Such as what you posted? Care to give me a solution that will run on my
customers server where they have a policy of not having a C compiler
installed on the server?
> but the OTHER danger, not discussing anything at all but
> the restricted subset of C proposed by some people here is even
> worst!
It is not a restricted subset unless you consider the entire language to
be a restricted subset of itself. Anyway there is plenty to discus.
--
Flash Gordon
CBFalconer
>
... snip ...
>
> I do agree that Jacob is one of persons who make it harder to talk
> about real life C applications here, but if one wants to shut him
> up, he can choose lot of other things, without the need to make
> this newsgroup like bunch of jerks who pretend real programs are
> not what they actually are.
He goes along for a while being fairly reasonable, and then breaks
out with one of his diatribes. The point here is that we don't
want to discuss the myriad extensions and libraries that are
available for C, but we do want to discuss things that have a firm
basis, such as an ISO standard.
Jacob has a whole mainstream newsgroup in which to espouse his
extensions and theories, i.e. comp.compilers.lcc. However he
insists on disturbing c.l.c with off-topic material, and in the
process is making himself look ridiculous, and generally annoying
the users. The result is that even if he says something
worthwhile, it is highly likely to be ignored or picked to pieces.
If he co-operated with the group, he would get more co-operation
from the group. It will probably take a year or two of
co-operation on his part before he will be taken seriously by most
regulars here.
Jacob is not alone with this problem. Note that such things as
regexs can be built entirely withing standard C - all that is
required for discussion of usage is to include the appropriate code
in the article, or at least a proper description of it with a link
to the ISO standard source.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
(of the idea that extensions to C are not part of the language)
>This means that there is no single serious program besides hello world
>ones that is written in C.
Must we do this *again*?
>
>OK?
No, no a thousand times no.
Just because you, with you apparently limited experience , have never
written a utility programme, filter etc, does not mean that such do
not exist and are not serious.
>Neither the linux kernel, nor all the network programs, nor any GUI
>program, nor any library that uses graphics, networking, threads,
>exception handling, nor the dynamic loader, nor any program that uses
>a directory structure (file directories aren't defined in standard
>C) nor all the embedded systems that use myriads of extensions
>adapted to each circuit board, etc.
Correct - none of that is ISO standard C. It all requires
platform-specific extensions.
>There are then NO PROGRAMS WRITTEN IN C.
Wrong.
>Satisfied?
Only that you're being idiotic again.
Mark McIntyre
<ian-...@hotmail.com> wrote:
>One has to draw the distinction between extensions to the language (the
>&& gcc extension and operator overloading) and platform specific
>libraries. It is a fairly straightforward exercise for a developer to
>implement a set of functions defined in a library
I'm not sure I'd entirely agree with that. It'd be fairly hard to
implement the Win32 libraries on most embedded systems, I suspect.
Unless "implement" includes returining a noop...
>Anything which conforms to the language defined in the current C
>standard is a C program, which includes programs that include
>non-standard headers.
Inasmuch as Geordie is still English. Which is to say not with respect
to passing an exam or making yourself understood in Arizona or
Auchtermuchty.
Richard Heathfield
> On Sat, 17 Feb 2007 20:08:57 +0100, in comp.lang.c , jacob navia
> <ja...@jacob.remcomp.fr> wrote:
>
<snip>
>>Neither the linux kernel, nor all the network programs, nor any GUI
>>program, nor any library that uses graphics, networking, threads,
>>exception handling, nor the dynamic loader, nor any program that uses
>>a directory structure (file directories aren't defined in standard
>>C) nor all the embedded systems that use myriads of extensions
>>adapted to each circuit board, etc.
>
> Correct - none of that is ISO standard C. It all requires
> platform-specific extensions.
Well, most of it does, but I've written plenty of graphics programs in
ISO C. Also, although C doesn't support directories, it allows you to
read information from a file, and you can certainly store file location
information in a file. I'd have thought that someone with sufficient
creative imagination to come up with a (platform-specific) LoadLibrary
hack to generate callable C functions at run-time would be able to
consider some of the possibilities inherent in C's support for files.
>>There are then NO PROGRAMS WRITTEN IN C.
>
> Wrong.
Indeed. I've written plenty of programs in straight C. Yes, I've written
plenty of programs in C-plus-extensions too, but the fact that programs
exist that are written in C-plus-extensions does not in any way imply
the non-existence of programs written in C-sans-extensions.
Yevgen Muntyan
> On Sun, 18 Feb 2007 11:15:17 +1300, in comp.lang.c , Ian Collins
> <ian-...@hotmail.com> wrote:
>
>> One has to draw the distinction between extensions to the language (the
>> && gcc extension and operator overloading) and platform specific
>> libraries. It is a fairly straightforward exercise for a developer to
>> implement a set of functions defined in a library
>
> I'm not sure I'd entirely agree with that. It'd be fairly hard to
> implement the Win32 libraries on most embedded systems, I suspect.
> Unless "implement" includes returining a noop...
It does, indeed. Point is that calling conventions, preprocessor magic,
syntax are all the same. If your program is
#include <windows.h>
int main (void)
{
return 0;
}
then it's a C program. If your program is
#include <magic.h>
int main (void)
{
return return 1.345e18u87;
}
then it's not.
>> Anything which conforms to the language defined in the current C
>> standard is a C program, which includes programs that include
>> non-standard headers.
>
> Inasmuch as Geordie is still English. Which is to say not with respect
> to passing an exam or making yourself understood in Arizona or
> Auchtermuchty.
It's good that there is this English language, and nobody knows
now what really is "correct" English, but it doesn't have much
to do with C. What language is the first program posted here? Is
it C? If not, is it "you tell me what it is?". Whatever, that *is*
C even if you don't like Jacob Navia.
Yevgen
CBFalconer
>
... snip ...
>
> magic, syntax are all the same. If your program is
>
> #include <windows.h>
> int main (void)
> {
> return 0;
> }
>
> then it's a C program. If your program is
No it isn't. If it had #include "windows.h" it would be. There is
no such header in standard C, but the user is allowed to create all
the headers he wishes elsewhere. All he has to do is provide them.
boa
> Yevgen Muntyan wrote:
> ... snip ...
>> It does, indeed. Point is that calling conventions, preprocessor
>> magic, syntax are all the same. If your program is
>>
>> #include <windows.h>
>> int main (void)
>> {
>> return 0;
>> }
>>
>> then it's a C program. If your program is
>
> No it isn't. If it had #include "windows.h" it would be. There is
> no such header in standard C, but the user is allowed to create all
> the headers he wishes elsewhere. All he has to do is provide them.
>
Chapter & Verse, please ;-)
Boa
Yevgen Muntyan
> Yevgen Muntyan wrote:
> ... snip ...
>> It does, indeed. Point is that calling conventions, preprocessor
>> magic, syntax are all the same. If your program is
>>
>> #include <windows.h>
>> int main (void)
>> {
>> return 0;
>> }
>>
>> then it's a C program. If your program is
>
> No it isn't. If it had #include "windows.h" it would be.
I'm afraid I can't understand this.
> There is
> no such header in standard C, but the user is allowed to create all
> the headers he wishes elsewhere. All he has to do is provide them.
And? Is this program C or not? If not, what is it (just curious
what ridiculous things people can invent instead of using standard
"strictly conforming" term). And please don't tell "this is not standard
C", I didn't say that. I am saying "it is a C program".
Yevgen
jacob navia
Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
and all the other nonsense. Besides, windows is considered harmful
here...
It is hopeless.
Richard Heathfield
<snip>
> Look. The criteria is simple. If I wrote it, it
> it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
> and all the other nonsense.
No. Whilst the criterion is indeed simple, that isn't it. The criterion
is simply that, if the code makes use of non-standard extensions, it's
off-topic here.
> Besides, windows is considered harmful here...
By some, yes, but that's irrelevant. What *is* relevant is that Windows
is considered off-topic here.
> It is hopeless.
It depends what you want. If you want a newsgroup where Windows
programming is topical, hope can be found at
comp.os.ms-windows.programmer.win32 - and if you want a newsgroup where
what you call "Navia C" is topical, it is likely - or at least possible
- that comp.compilers.lcc will prove hopeful for you. But if you want a
newsgroup where the C programming language, unfettered by extensions,
is discussed, then comp.lang.c is that newsgroup.
Keith Thompson
> Yevgen Muntyan wrote:
>>
> ... snip ...
>>
>> It does, indeed. Point is that calling conventions, preprocessor
>> magic, syntax are all the same. If your program is
>>
>> #include <windows.h>
>> int main (void)
>> {
>> return 0;
>> }
>>
>> then it's a C program. If your program is
>
> No it isn't. If it had #include "windows.h" it would be. There is
> no such header in standard C, but the user is allowed to create all
> the headers he wishes elsewhere. All he has to do is provide them.
It is a "conforming program", as defined in C99 4p7, as long as
there's some conforming C implementation that accepts it.
Keith Thompson
> it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
> and all the other nonsense. Besides, windows is considered harmful
> here...
>
> It is hopeless.
It is hopeless as long as you have that attitude.
I've been reading your postings here for a long time. Trust me on
this: sarcasm doesn't work for you. It's not possible to have a
constructive discussion with you if you insist on parodying what you
think are other people's opinions. It simply guarantees that you will
not be taken seriously.
On the other hand, if you write what *you* believe, and perhaps even
back it up with evidence, the worst that can happen is that people
will disagree with you. It's even possible that somebody might learn
something.
I've told you this before, and I'm not optimistic that it will get
through this time.
Mark McIntyre
<muntyan.r...@tamu.edu> wrote:
>CBFalconer wrote:
>> No it isn't. If it had #include "windows.h" it would be.
>
>I'm afraid I can't understand this.
What CBF was trying to say is the <> and "" forms of #include
potentially search different places. By convention. the <> form
searches your system header paths, while "" searches
application-specific paths. However this has nothing to do with
whether a header is ISO standard or not, so the point isn't relevant.
>And? Is this program C or not? If not, what is it (just curious
>what ridiculous things people can invent instead of using standard
>"strictly conforming" term). And please don't tell "this is not standard
>C", I didn't say that. I am saying "it is a C program".
It is _potentially_ a C programme. However since we have no idea at
all what is in "windows.h", we can't tell what nonstandard and
nonportable atrocities might be therein. Any one of these could render
the code no longer C.
The point CBF was making here is that had the user supplied the
contents of windows.h, we oculd have been certain whether it was C or
not. As it is, it could be packed with assembler, platform-specific
memory access which violates C standards, etc etc etc.
Mark McIntyre
<ja...@jacob.remcomp.fr> wrote:
>Look. The criteria is simple. If I wrote it, it
>it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
Don't be such an idiot. The criterion is simple - if it contains
platform-specific stuff its offtopic here, irrespective of who wrote
it. If it contains nonstandard constructs, grammar etc then its not C.
Again irrespective of who wrote it.
>and all the other nonsense. Besides, windows is considered harmful
>here...
Bullshit. Now you're displaying your own prejudices.
>It is hopeless.
I agree. You are determined to martyr yourself on a nonexistent altar,
no point trying to stop you I think.
CBFalconer
>From N869:
6.10.2 Source file inclusion
Constraints
[#1] A #include directive shall identify a header or source
file that can be processed by the implementation.
Semantics
[#2] A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a
header identified uniquely by the specified sequence between
the < and > delimiters, and causes the replacement of that
directive by the entire contents of the header. How the
places are specified or the header identified is
implementation-defined.
Note that no such actual file need exist, and that the response to
the #include <filename> may be entirely contained within the
compiler.
Yevgen Muntyan
> On Mon, 19 Feb 2007 06:30:00 GMT, in comp.lang.c , Yevgen Muntyan
> <muntyan.r...@tamu.edu> wrote:
>
>> CBFalconer wrote:
>
>>> No it isn't. If it had #include "windows.h" it would be.
>> I'm afraid I can't understand this.
>
> What CBF was trying to say is the <> and "" forms of #include
> potentially search different places. By convention. the <> form
> searches your system header paths, while "" searches
> application-specific paths. However this has nothing to do with
> whether a header is ISO standard or not, so the point isn't relevant.
Now I got it, I didn't notice <> vs "". Well, that's a wrong statement.
C standard says as much about #include "windows.h" as about
#include <windows.h>. Namely, using either form makes your program
not strictly conforming. And if you talk real compilers, you can
make the compiler pick your header instead of system one
when you use #include <windows.h>, and vice versa. In any case,
it's out of standard business. So are we talking about common
sense here or about what?
>> And? Is this program C or not? If not, what is it (just curious
>> what ridiculous things people can invent instead of using standard
>> "strictly conforming" term). And please don't tell "this is not standard
>> C", I didn't say that. I am saying "it is a C program".
>
> It is _potentially_ a C programme. However since we have no idea at
Yes you do. That's the point. You know pretty well the program was
a C program but you wanted to tell couple nice words to Jacob Navia,
so you did "beep beep not C". Bullshit.
> all what is in "windows.h", we can't tell what nonstandard and
> nonportable atrocities might be therein. Any one of these could render
> the code no longer C.
Yes it could, sure.
> The point CBF was making here is that had the user supplied the
> contents of windows.h, we oculd have been certain whether it was C or
> not. As it is, it could be packed with assembler, platform-specific
> memory access which violates C standards, etc etc etc.
Well, the point was hidden pretty well. This is obvious, the
non-standard header may do what it wants to. So why do you
say *not C* if you do *not* know that? I simply assume that
header is indeed the famous windows.h thing, windows C api,
for C programs. You?
Yevgen
Richard Heathfield
> You are determined to martyr yourself on a nonexistent altar
An altar could be arranged.
Keith Thompson
> Yevgen Muntyan wrote:
>>
> ... snip ...
>>
>> It does, indeed. Point is that calling conventions, preprocessor
>> magic, syntax are all the same. If your program is
>>
>> #include <windows.h>
>> int main (void)
>> {
>> return 0;
>> }
>>
>> then it's a C program. If your program is
>
> No it isn't. If it had #include "windows.h" it would be. There is
> no such header in standard C, but the user is allowed to create all
> the headers he wishes elsewhere. All he has to do is provide them.
There's a difference between "not a C program" and "off-topic in
comp.lang.c". The above is a C program, though not a portable one,
and saying it isn't just muddies the waters. The program is merely
off-topic in comp.lang.c.
boa
My impression was that you describe programs with non-standard header
files within <> as "not C". The standard is silent on this issue,
AFAICT. So
#include <windows.h>
int main(void) { return 0;}
is a valid C program, just as this snippet is.
#include "stdio.h"
int main(void) {return 0;}
Source file inclusion is all implementation-defined, according to C99
§6.10.2. Even "STDIO.H" and "sTdIo.H" seems to be perfectly fine file
names too, according to 6.10.2#5 <shudder>
Boa
Kenny McCormack
Keith Thompson <ks...@mib.org> wrote:
...
>There's a difference between "not a C program" and "off-topic in
>comp.lang.c". The above is a C program, though not a portable one,
>and saying it isn't just muddies the waters.
Indeed.
>The program is merely off-topic in comp.lang.c.
How very reasonable of you to say so. Unfortunately, some of your fellow
twits-in-arms say otherwise (and have done so repeatedly time and again
in this ng).
Richard Bos
> CBFalconer wrote:
> > There is
> > no such header in standard C, but the user is allowed to create all
> > the headers he wishes elsewhere. All he has to do is provide them.
>
> And? Is this program C or not? If not, what is it (just curious
> what ridiculous things people can invent instead of using standard
> "strictly conforming" term). And please don't tell "this is not standard
> C", I didn't say that. I am saying "it is a C program".
You're the one using non-Standard extensions and claiming they're
perfectly good C. I suggest that _you_ come up with your definition of
what is and is not a C program. Be careful, now: some definitions are
trickier than they first seem. For example, simply replying "any
conforming program" would have some unforeseen consequences...
Richard
Yevgen Muntyan
Try reading the thread, you'll find some discussion of this, what
you're saying and more. Anyway, could you please confirm that
the program was not C? And could you tell (I am just curious) what
you'd call it? No, I am not asking you to invent definitions or
something, just wondering what you call that, "C-like", "a piece
of text resembling a C program", "a piece of text which looks
like java to me"... Just what you think when you see such a piece
of code, i.e. 99% of "C" code you see (quotes used because you
might say it's not C and so on).
Yevgen
Andrew Poelstra
It isn't C because you used WCHAR without defining it, and so it was a
syntax error.
--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.
Chris Dollin
> On Thu, 2007-02-22 at 10:19 +0000, Yevgen Muntyan wrote:
>> Richard Bos wrote:
>> > Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>> > You're the one using non-Standard extensions and claiming they're
>> > perfectly good C. I suggest that _you_ come up with your definition of
>> > what is and is not a C program. Be careful, now: some definitions are
>> > trickier than they first seem. For example, simply replying "any
>> > conforming program" would have some unforeseen consequences...
>>
>> Try reading the thread, you'll find some discussion of this, what
>> you're saying and more. Anyway, could you please confirm that
>> the program was not C? And could you tell (I am just curious) what
>> you'd call it? No, I am not asking you to invent definitions or
>> something, just wondering what you call that, "C-like", "a piece
>> of text resembling a C program", "a piece of text which looks
>> like java to me"... Just what you think when you see such a piece
>> of code, i.e. 99% of "C" code you see (quotes used because you
>> might say it's not C and so on).
>>
>
> It isn't C because you used WCHAR without defining it, and so it was a
> syntax error.
I think it's at least plausible that some fragment of text "is C"
if there is standard C header and footer text that can surround it
and make it legal & grammatical (and non-trivial [1]).
Otherwise if I said "consider the fragment `int i = i + 1;`" I could
be dismissed because that fragment wasn't C.
[1] Otherwise the header "/*" and footer "*/" would ruin (most) things.
--
Chris "electric hedgehog" Dollin
"Reaching out for mirrors hidden in the web." - Renaissance, /Running Hard/
Yevgen Muntyan
> On Thu, 2007-02-22 at 10:19 +0000, Yevgen Muntyan wrote:
>> Richard Bos wrote:
>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>> You're the one using non-Standard extensions and claiming they're
>>> perfectly good C. I suggest that _you_ come up with your definition of
>>> what is and is not a C program. Be careful, now: some definitions are
>>> trickier than they first seem. For example, simply replying "any
>>> conforming program" would have some unforeseen consequences...
>> Try reading the thread, you'll find some discussion of this, what
>> you're saying and more. Anyway, could you please confirm that
>> the program was not C? And could you tell (I am just curious) what
>> you'd call it? No, I am not asking you to invent definitions or
>> something, just wondering what you call that, "C-like", "a piece
>> of text resembling a C program", "a piece of text which looks
>> like java to me"... Just what you think when you see such a piece
>> of code, i.e. 99% of "C" code you see (quotes used because you
>> might say it's not C and so on).
>>
>
> It isn't C because you used WCHAR without defining it, and so it was a
> syntax error.
There was no WCHAR even in the original JN's program, nor in my
purified version
#include <windows.h>
int main (void)
{
return 0;
}
Yevgen
Mark McIntyre
<muntyan.r...@tamu.edu> wrote:
>Mark McIntyre wrote:
>> On Mon, 19 Feb 2007 06:30:00 GMT, in comp.lang.c , Yevgen Muntyan
>
>>> And? Is this program C or not?
>>
>> It is _potentially_ a C programme. However since we have no idea at
>
>Yes you do. That's the point.
No, you don't. That is indeed the point. If stdlib.h were included,
you would know it was a C programme, since stdlib.h is a standard
header. if foobar.h is included, you have no idea at all unless you
have the contents of foobar.h
>You know pretty well the program was
>a C program but you wanted to tell couple nice words to Jacob Navia,
You think I have a vendetta against Jacob. You're wrong. I do have an
objection to people posting gratuitously offtopic stuff here tho.
Windows-specific code is offtopic.
>so you did "beep beep not C". Bullshit.
Horsefeathers.
>> The point CBF was making here is that had the user supplied the
>> contents of windows.h, we oculd have been certain whether it was C or
>> not. As it is, it could be packed with assembler, platform-specific
>> memory access which violates C standards, etc etc etc.
>
>Well, the point was hidden pretty well.
Possibly. See my sig.
>say *not C* if you do *not* know that? I simply assume that
We know what "assume" makes out of you and me.
>header is indeed the famous windows.h thing, windows C api,
>for C programs. You?
I have several headers called Windows.h, two of which deal with the
win32API, but for different compilers and with slightly different
contents. Both of them give rise to compilation errors during
compilation in ISO C mode. A third is for PalmOS as far as I remember
(I haven't used it in a while). A few years ago, I worked for a
company that gathered together all their GUI control declarations into
a file called - you guess.
--
Mark McIntyre
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield
Richard Bos
> Richard Bos wrote:
> > You're the one using non-Standard extensions and claiming they're
> > perfectly good C. I suggest that _you_ come up with your definition of
> > what is and is not a C program. Be careful, now: some definitions are
> > trickier than they first seem. For example, simply replying "any
> > conforming program" would have some unforeseen consequences...
>
> Try reading the thread, you'll find some discussion of this, what
> you're saying and more.
What I find is a whole lot of "yes it is", "no it isn't", "yes it is";
but nothing that makes it clear what _you_ consider to be C. Since
you're the one who is telling the rest of us that we're wrong, perhaps
you'd like to enlighten us, rather than just contradicting.
> Anyway, could you please confirm that the program was not C?
Of course it wasn't.
> And could you tell (I am just curious) what you'd call it?
That one? Pseudo-Windows pseudo-C compatible-with-nothing crap.
> Just what you think when you see such a piece of code, i.e.
> 99% of "C" code you see
I see a good deal of utter tripe, but 99% the same kind of tripe as that
chimaera posted upthread would be rather an exaggeration.
Richard
Yevgen Muntyan
> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>
>> Richard Bos wrote:
>>> You're the one using non-Standard extensions and claiming they're
>>> perfectly good C. I suggest that _you_ come up with your definition of
>>> what is and is not a C program. Be careful, now: some definitions are
>>> trickier than they first seem. For example, simply replying "any
>>> conforming program" would have some unforeseen consequences...
>> Try reading the thread, you'll find some discussion of this, what
>> you're saying and more.
>
> What I find is a whole lot of "yes it is", "no it isn't", "yes it is";
> but nothing that makes it clear what _you_ consider to be C. Since
> you're the one who is telling the rest of us that we're wrong, perhaps
> you'd like to enlighten us, rather than just contradicting.
Well, since it's indeed hard to read, and much easier just to pick
some words and argue about them, I'll quote myself:
-----------------------------------------------------
... we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
is what I call nonsense, simply because it's too restrictive - if
one accepts such definition of a "C program", then all those C
programmers out there are writing programs in some fancy language
which is not C, and all those C programs out there are not C
programs. Then, I think the standard exists to make people able
to write C programs using extensions. And it uses term "strictly
conforming" exactly to distinguish programs which are completely
described and programs which use extensions but are still C programs,
but to not restrict itself only to those strictly conforming
programs. The syntax and semantics of "a C program" have very big
value, what would be the point of having the standard which simply
stops working as soon as non-standard header is used?
I personally don't have that wider definition, and I don't think
anyone could come up with something sensible here. And it's the
reason why *on-topic* here are only strictly conforming programs.
But there is more to C than programs using only standard features.
For instance, a C program which uses POSIX regex to work with
some strings, or a program which uses windows API to print list of
processes, are C programs as long as they don't use some fancy
non-C syntax or mechanics (insert "semantics" here).
-----------------------------------------------------
A long quote, but it was hard enough to write that, and I didn't
try to edit/compress it.
>> Anyway, could you please confirm that the program was not C?
>
> Of course it wasn't.
>
>> And could you tell (I am just curious) what you'd call it?
>
> That one? Pseudo-Windows pseudo-C compatible-with-nothing crap.
>
>> Just what you think when you see such a piece of code, i.e.
>> 99% of "C" code you see
>
> I see a good deal of utter tripe, but 99% the same kind of tripe as that
> chimaera posted upthread would be rather an exaggeration.
How do you distinguish "C code" from "pseudo-C crap". As far as the
standard is concerned, once you have any non-standard #include
in your file, you get "pseudo-C crap". Once you have one file in
your program which uses a non-standard feature (even if the other
thousand files are perfect standard C), then the program is "pseudo-C
crap". So the question stands. You like to write pseudo-C crap,
it's fine; I still believe there are lot of C programmers writing
C programs, which are C programs even if they use POSIX api, windows
api, foobar api, etc.
Somehow almost all programs on my computer are written in C. You
may say they are written in "Pseudo-Unix pseudo-C crap", it's your
choice. But it's not a sensible choice.
Yevgen
Yevgen Muntyan
Um, maybe the "crap" is applied to JN's code, which may or may not
be of any value for you. I was asking about my two precious pieces of
code. So, here is the program:
#include <windows.h>
int main (void)
{
return 0;
}
Yevgen
CBFalconer
>
... snip ...
>
> be of any value for you. I was asking about my two precious pieces
> of code. So, here is the program:
>
> #include <windows.h>
> int main (void)
> {
> return 0;
> }
As I said before, if you change that to:
#include "windows.h"
it becomes a C program, because you can then create a (possibly
empty) windows.h file in an appropriate place (which I won't
detail). As it is there is no need to accept it. With the change,
discussing it here requires disclosure of the content of windows.h.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Keith Thompson
> Yevgen Muntyan wrote:
>>
> ... snip ...
>>
>> Um, maybe the "crap" is applied to JN's code, which may or may not
>> be of any value for you. I was asking about my two precious pieces
>> of code. So, here is the program:
>>
>> #include <windows.h>
>> int main (void)
>> {
>> return 0;
>> }
>
> As I said before, if you change that to:
>
> #include "windows.h"
>
> it becomes a C program, because you can then create a (possibly
> empty) windows.h file in an appropriate place (which I won't
> detail). As it is there is no need to accept it. With the change,
> discussing it here requires disclosure of the content of windows.h.
Depending on the implementation, you might be able to create a
windows.h file in an appropriate place for "#include <windows.h>"
to find it. The search paths for <foo.h> and "foo.h" can even be
identical. And if you don't create such a file, and it doesn't
already exist, then either version of the program will fail to
compile.
In my opinion, it's C, but it's not portable C, and it's off-topic
here (unless you provide the contents of the windows.h header).
Beej Jorgensen
Mark McIntyre <markmc...@spamcop.net> wrote:
>If stdlib.h were included, you would know it was a C programme, since
>stdlib.h is a standard header.
Or *would* you?
7.1.2 paragraph 3:
If a file with the same name as one of the above < and > delimited
sequences, not provided as part of the implementation, is placed in
any of the standard places that are searched for included source
files, the behavior is undefined.
Sometimes assumptions about a poster's code just have to be made.
-Beej
Keith Thompson
> In article <qt5st2p2qdkctb7km...@4ax.com>,
> Mark McIntyre <markmc...@spamcop.net> wrote:
>>If stdlib.h were included, you would know it was a C programme, since
>>stdlib.h is a standard header.
>
> Or *would* you?
>
> 7.1.2 paragraph 3:
>
> If a file with the same name as one of the above < and > delimited
> sequences, not provided as part of the implementation, is placed in
> any of the standard places that are searched for included source
> files, the behavior is undefined.
Interesting. That says that if I place a "stdlib.h" file in one of
the places searched for a
#include "stdlib.h"
directive but *not* for a
#include <stdlib.h>
directive, then the behavior is undefined. I suspect that wasn't the
intent. In the absence of 7.1.2p3, such a file wouldn't cause any
problems, because the compiler wouldn't see it. It also implies that
the behavior becomes undefined whether the program attempts to include
the header or not.
Note that, for some implementations, there may be no such places, the
search paths for <foo.h> and "foo.h" might be identical.
I also note that, by creating and installing such a file, I can
magically make my implementation 100% conforming (though not usefully
so); it makes all behavior undefined, so anything the compiler does is
conforming. But the implementation can't take advantage of this
trick, because the file is "not provided as part of the
implementation".
Flash Gordon
> Richard Bos wrote:
>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>
>>> Richard Bos wrote:
>>>> You're the one using non-Standard extensions and claiming they're
>>>> perfectly good C. I suggest that _you_ come up with your definition of
>>>> what is and is not a C program. Be careful, now: some definitions are
>>>> trickier than they first seem. For example, simply replying "any
>>>> conforming program" would have some unforeseen consequences...
>>> Try reading the thread, you'll find some discussion of this, what
>>> you're saying and more.
>>
>> What I find is a whole lot of "yes it is", "no it isn't", "yes it is";
>> but nothing that makes it clear what _you_ consider to be C. Since
>> you're the one who is telling the rest of us that we're wrong, perhaps
>> you'd like to enlighten us, rather than just contradicting.
>
> Well, since it's indeed hard to read, and much easier just to pick
> some words and argue about them, I'll quote myself:
>
> -----------------------------------------------------
> ... we have a choice here: call a "C program" only
> strictly conforming programs or use a wider definition. The former
<snip>
> I personally don't have that wider definition, and I don't think
> anyone could come up with something sensible here.
In other words you think everyone who places any kind of limit on what a
C program is is wrong.
#include <crapit>
BEGIN
print "This is C"
END
Must be C by your definition since crapit might possibly be a header
that makes it C. Or it might be a header that makes it C++ but not C. Or
maybe some other language.
> And it's the
> reason why *on-topic* here are only strictly conforming programs.
> But there is more to C than programs using only standard features.
Actually, a highly system specific program could be topical within
certain limits depending on what the question being asked along with the
program is. For example, if the question was "how much of the program is
standard C?" then it could be considered an entirely topical post even
if the only thing standard was the declaration of main. It could even
lead to interesting discussions about why certain things were not
covered by the standard.
> For instance, a C program which uses POSIX regex to work with
> some strings, or a program which uses windows API to print list of
> processes, are C programs as long as they don't use some fancy
> non-C syntax or mechanics (insert "semantics" here).
No, it is a POSIX-C program or a Windows-C program or whatever. If well
written a large percentage of the code may well be C code, but that does
not make it as a hole a C program whether it uses __asm() to introduce
some assembler code, or calls a function written by the author in
assembler, or calls a function written by MS or the GNU team in
something other than C. You could call it a "mostly C program" if you
prefer.
Personally I tend to talk about C code rather than C programs. There is
a lit more C code around than C programs, and it could even be that you
have a 10000 line file with 5 lines of C code in it!
> -----------------------------------------------------
>
> A long quote, but it was hard enough to write that, and I didn't
> try to edit/compress it.
It does not address what you think is and is not C, it only says you
don't agree with C code being only code which is specified (possibly as
being implementation defined) by the C standard.
>>> Anyway, could you please confirm that the program was not C?
>>
>> Of course it wasn't.
>>
>>> And could you tell (I am just curious) what you'd call it?
>>
>> That one? Pseudo-Windows pseudo-C compatible-with-nothing crap.
>>
>>> Just what you think when you see such a piece of code, i.e.
>>> 99% of "C" code you see
>>
>> I see a good deal of utter tripe, but 99% the same kind of tripe as that
>> chimaera posted upthread would be rather an exaggeration.
>
> How do you distinguish "C code" from "pseudo-C crap". As far as the
> standard is concerned, once you have any non-standard #include
> in your file, you get "pseudo-C crap".
Only if the non-standard header is not provided or is not itself C code.
If the non-standard header has no impact on the rest of the file then
only that one line is "pseudo-C crap", if you don't know the contents of
the header then the entire presented code can validly be considered as
"pseudo-C crap".
> Once you have one file in
> your program which uses a non-standard feature (even if the other
> thousand files are perfect standard C), then the program is "pseudo-C
> crap". So the question stands. You like to write pseudo-C crap,
> it's fine; I still believe there are lot of C programmers writing
> C programs, which are C programs even if they use POSIX api, windows
> api, foobar api, etc.
Personally since I started writing C hardly any programs I have written
have been C programs (or do yo consider " LAC *+,AR0" to be C?) but I
have written a lot of C code that has been incorporated with other stuff
to produce programs.
> Somehow almost all programs on my computer are written in C. You
> may say they are written in "Pseudo-Unix pseudo-C crap", it's your
> choice. But it's not a sensible choice.
A lot of programs are written mostly in C, but if the program as a whole
is not written in C then calling it a C program is misleading, although
saying it is mostly written in C is not.
If I write a program with 25% assembler, 25% C, 25% Java and 25%
Fortran, what language is the program written in? My answer is "a mixture".
--
Flash Gordon
Beej Jorgensen
Keith Thompson <ks...@mib.org> wrote:
>> 7.1.2 paragraph 3:
>>
>> If a file with the same name as one of the above < and > delimited
>> sequences, not provided as part of the implementation, is placed in
>> any of the standard places that are searched for included source
>> files, the behavior is undefined.
>
>Interesting. That says that if I place a "stdlib.h" file in one of
>the places searched for a
> #include "stdlib.h"
>directive but *not* for a
> #include <stdlib.h>
Hmmm. That wasn't my read... Elaborate.
Why not for <stdlib.h>, especially since "" is a "superset" (so to
speak) of <>?
6.10.2p2 says:
A preprocessing directive of the form
#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters, and causes the replacement of that directive by the
entire contents of the header. How the places are specified or the
header identified is implementation-defined.
(Emphasis on the verb "search".)
The sketchiest part seems to me to be what is meant by "standard places"
in 7.1.2p3. I can only assume that is another way of saying
the "implementation-defined places" of 6.10.2p2 (<>). p3 ("") says the
file is searched for in an "implementation-defined manner" devolving to
the rules of p2, but makes no reference to "place".
-Beej
Yevgen Muntyan
> Yevgen Muntyan wrote:
> ... snip ...
>> Um, maybe the "crap" is applied to JN's code, which may or may not
>> be of any value for you. I was asking about my two precious pieces
>> of code. So, here is the program:
>>
>> #include <windows.h>
>> int main (void)
>> {
>> return 0;
>> }
>
> As I said before, if you change that to:
>
> #include "windows.h"
>
> it becomes a C program, because you can then create a (possibly
> empty) windows.h file in an appropriate place (which I won't
> detail). As it is there is no need to accept it. With the change,
> discussing it here requires disclosure of the content of windows.h.
As I said before, what you are saying isn't guaranteed by the standard.
The program using #include <windows.h> may be conforming, or you may
not be able to create your header named "windows.h", or a program
using either form may fail to be processed.
Yevgen
Yevgen Muntyan
Yes, it *could* be a C program, and it's indeed not hard to write that
crapit. It all depends on what in <crapit>, and whether compiler
will accept that crapit. In case of original program using windows.h
you *do* know what windows.h is, and you do know that's a C program.
If you don't know what windows.h was, you can ask.
> > And it's the
>> reason why *on-topic* here are only strictly conforming programs.
>> But there is more to C than programs using only standard features.
>
> Actually, a highly system specific program could be topical within
> certain limits depending on what the question being asked along with the
> program is. For example, if the question was "how much of the program is
> standard C?" then it could be considered an entirely topical post even
> if the only thing standard was the declaration of main. It could even
> lead to interesting discussions about why certain things were not
> covered by the standard.
>
>> For instance, a C program which uses POSIX regex to work with
>> some strings, or a program which uses windows API to print list of
>> processes, are C programs as long as they don't use some fancy
>> non-C syntax or mechanics (insert "semantics" here).
>
> No, it is a POSIX-C program or a Windows-C program or whatever. If well
> written a large percentage of the code may well be C code, but that does
> not make it as a hole a C program whether it uses __asm() to introduce
> some assembler code, or calls a function written by the author in
> assembler, or calls a function written by MS or the GNU team in
> something other than C. You could call it a "mostly C program" if you
> prefer.
>
> Personally I tend to talk about C code rather than C programs. There is
> a lit more C code around than C programs, and it could even be that you
> have a 10000 line file with 5 lines of C code in it!
So you prefer to use "C code" for C code, and call only strictly
conforming programs "C programs"? Completely fine for me, but note
that it's just as non-standard as my version. And just as vague.
It's as vague because for instance your above example with crapit
again could be C code, if you insert appropriate defines. From the
other hand, any C code may be screwed up using macro definitions.
And we get back to the fact that it's possible to say for sure
if something is standard C or not only for complete program.
Once you start saying
int a = 2;
or
int func (void)
{
return 0;
}
is C code, you get away from the safe route (standardise) and get to
area of "it looks and breathes like C", the stuff I am talking about.
In other words, you are saying my "definition" (which I don't really
have) is no good, and you just use another one, which is just as
non-strict as mine. Then you can ignore the question about what
"C programs" are since you can think about "C code" instead :)
>> -----------------------------------------------------
>>
>> A long quote, but it was hard enough to write that, and I didn't
>> try to edit/compress it.
>
> It does not address what you think is and is not C, it only says you
> don't agree with C code being only code which is specified (possibly as
> being implementation defined) by the C standard.
I didn't discuss "C code" term at all. I can tell that it seems
we have same ideas about what is C code and what isn't though.
It can't be made C even using preprocessor tricks, so it's not C at all.
I guess.
> but I
> have written a lot of C code that has been incorporated with other stuff
> to produce programs.
>
>> Somehow almost all programs on my computer are written in C. You
>> may say they are written in "Pseudo-Unix pseudo-C crap", it's your
>> choice. But it's not a sensible choice.
>
> A lot of programs are written mostly in C, but if the program as a whole
> is not written in C then calling it a C program is misleading, although
> saying it is mostly written in C is not.
>
> If I write a program with 25% assembler, 25% C, 25% Java and 25%
> Fortran, what language is the program written in? My answer is "a mixture".
Yes, it's a mixture. But I wasn't talking about such cases. I was
talking about programs which have 100% C code. Using non-standard
features like "libraries" though.
Yevgen
Keith Thompson
> In article <lntzxca...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
>>> 7.1.2 paragraph 3:
>>>
>>> If a file with the same name as one of the above < and > delimited
>>> sequences, not provided as part of the implementation, is placed in
>>> any of the standard places that are searched for included source
>>> files, the behavior is undefined.
>>
>>Interesting. That says that if I place a "stdlib.h" file in one of
>>the places searched for a
>> #include "stdlib.h"
>>directive but *not* for a
>> #include <stdlib.h>
>
> Hmmm. That wasn't my read... Elaborate.
>
> Why not for <stdlib.h>, especially since "" is a "superset" (so to
> speak) of <>?
Sorry, the scope of the "*not*" was unclear.
Suppose the compiler searches for <foo.h> in /usr/include, and for
"foo.h" in $HOME/include and then /usr/include (these are just
arbitrary examples). 7.1.2p3, as I read it, says that if I place a
"stdlib.h" file in $HOME/include (which, as I wrote above, is one of
the places searched for "stdlib.h", but not one of the places searched
for <stdlib.h>), then the behavior is undefined.
If I place a "stdlib.h" file in /usr/include, of course, it also
causes UB.
And I just noticed that 7.1.2p3 talks about "a file with the same
name", which ignores the mapping specified by 6.10.2. In 6.10.2,
it says that <foo.h> refers to
a header identified uniquely by the specified sequence between the
< and > delimiters
whereas "foo.h" refers to
the source file identified by the specified sequence between the "
delimiter
What does "identified by" mean here? Is "foo.h" actually the *name*
of the file (as would be accepted by fopen(), or is it subject to the
same mapping as <foo.h>?
The implementation shall provide unique mappings for sequences
consisting of one or more letters or digits (as defined in 5.2.1)
followed by a period (.) and a single letter. The first character
shall be a letter. The implementation may ignore the distinctions
of alphabetical case and restrict the mapping to eight significant
characters before the period.
Yevgen Muntyan
Given that the whole include business is implementation-defined,
7.1.2.3 is rather just an additional "don't mess with implementation"
hint. Especially given that the standard doesn't require the very
possibility to place a source file into some place. From the other
hand, programs having "string.h" header do exists, even the alive
supported ones.
> And I just noticed that 7.1.2p3 talks about "a file with the same
> name", which ignores the mapping specified by 6.10.2. In 6.10.2,
> it says that <foo.h> refers to
>
> a header identified uniquely by the specified sequence between the
> < and > delimiters
>
> whereas "foo.h" refers to
>
> the source file identified by the specified sequence between the "
> delimiter
>
> What does "identified by" mean here? Is "foo.h" actually the *name*
> of the file (as would be accepted by fopen(), or is it subject to the
> same mapping as <foo.h>?
It means the latter (not *the same* though), since the standard simply
doesn't talk about files at all, i.e. it doesn't say source files should
be "real" files on disk (you know, those bizarre implementations where
there is no disk and files or which use database or streams or
anything). fopen() is irrelevant since it's what happens on the target
system in compiled program, not what compiler does.
The mapping may or may not be the same as for <foo.h> (and it
isn't in practice with at least one popular compiler, and it must
not be the same according to the common practice of "yours.h" and
<system.h>).
But 7.10.2.3 doesn't ignore 6.10.2. It just uses human language,
it says exactly what it says: "you put stdlib.h into one of those
places and you get UB", even though it doesn't define what it means
to put a source file into some place. It's not the only place where it
talks humanish, isn't it?
Yevgen
Keith Thompson
But I think it goes beyond "don't mess with the implementation".
>> And I just noticed that 7.1.2p3 talks about "a file with the same
>> name", which ignores the mapping specified by 6.10.2. In 6.10.2,
>> it says that <foo.h> refers to
>> a header identified uniquely by the specified sequence between
>> the
>> < and > delimiters
>> whereas "foo.h" refers to
>> the source file identified by the specified sequence between the
>> "
>> delimiter
>> What does "identified by" mean here? Is "foo.h" actually the *name*
>> of the file (as would be accepted by fopen(), or is it subject to the
>> same mapping as <foo.h>?
>
> It means the latter (not *the same* though), since the standard simply
> doesn't talk about files at all, i.e. it doesn't say source files should
> be "real" files on disk (you know, those bizarre implementations where
> there is no disk and files or which use database or streams or
> anything). fopen() is irrelevant since it's what happens on the target
> system in compiled program, not what compiler does.
> The mapping may or may not be the same as for <foo.h> (and it
> isn't in practice with at least one popular compiler, and it must
> not be the same according to the common practice of "yours.h" and
> <system.h>).
You're right, fopen() is irrelevant; I was trying to use it to define
what a file name is.
As for the "mapping", the way I tend to think of it is something like
this: The compiler searches for include files and/or headers in one or
more "places". You can (maybe) have two files with the same name in
two different "places". The mapping mentioned in 6.10.2 maps the
thing between <> or "" to a file name; the compiler searches for a
file with that name in one or more "places". The mapping and the
search path (set of "places") are two different things. (I'm not
entirely sure my mental model is supported by the standard.)
> But 7.10.2.3 doesn't ignore 6.10.2. It just uses human language,
> it says exactly what it says: "you put stdlib.h into one of those
> places and you get UB", even though it doesn't define what it means
> to put a source file into some place. It's not the only place where it
> talks humanish, isn't it?
The problem, I think, is that 7.10.2.3 is too expansive about which
"places" need to be protected. To invent some terminology, let's say
the compiler searches for <foo.h> in the "angle-bracket places", and
for "foo.h" in the "quotation-mark places" followed by the
"angle-bracket places". Certainly installing a file called stdlib.h
in one of the angle-bracket places constitutes messing with the
implementation, but installing such a file in one of the
quotation-mark places should be ok. Logically, that shouldn't affect
any program that has a #include <stdlib.h>. IMHO, it would make more
sense for 7.10.2.3 to say only that putting stdlib.h in one of the
angle-bracket places invokes UB.
CBFalconer
>
... snip ...
>
> If I write a program with 25% assembler, 25% C, 25% Java and 25%
> Fortran, what language is the program written in? My answer is
> "a mixture".
Such a 'program' is not portable, since they depend on the
mechanisms provided for linking, function calling, etc. It MAY
work on some system that imposes the same requirements on the
object files generated by each compiler. Since things are system
dependent, they are not topical here. Even Ada, which has built-in
provision for linking C code, depends on the compilation of the C
with a compiler compatible with the Ada compiler.
Yevgen Muntyan
I missed the fact that UB is quite different for an implementation
from what it is for a user. I was thinking rather about writing
portable code, which means not abusing implementations and not using
standard header names (the "don't mess" part). But indeed UB is UB,
and it's not "just" something, it's undefined.
I believe it's not like that. There are two mappings, one for "..."
and another one for <...>. If implementation uses files (i.e. usual
case, for simplicity), then those two mappings map characters sequences
to *absolute* file paths. In other words, the part about mappings in
6.10.2.5 is saying that all '#include "foo.h"' will use the same file in
current translation unit (or in the whole program?), as well as all
'#include <foo.h>' will do the same thing, or the preprocessing
directive (every #include "foo.h", not just the second one, for
instance) will cause failure to process the file.
It seems to me that 6.10.2.5 also could imply that you are allowed
to have two different headers, foo.h and bar.h (they start with letter,
end with .h, not more than eight characters, etc.) But the standard
doesn't require the very possibility to have a custom header file,
so it's way too vague.
>> But 7.10.2.3 doesn't ignore 6.10.2. It just uses human language,
>> it says exactly what it says: "you put stdlib.h into one of those
>> places and you get UB", even though it doesn't define what it means
>> to put a source file into some place. It's not the only place where it
>> talks humanish, isn't it?
>
> The problem, I think, is that 7.10.2.3 is too expansive about which
> "places" need to be protected. To invent some terminology, let's say
> the compiler searches for <foo.h> in the "angle-bracket places", and
> for "foo.h" in the "quotation-mark places" followed by the
> "angle-bracket places". Certainly installing a file called stdlib.h
> in one of the angle-bracket places constitutes messing with the
> implementation, but installing such a file in one of the
> quotation-mark places should be ok. Logically, that shouldn't affect
> any program that has a #include <stdlib.h>. IMHO, it would make more
> sense for 7.10.2.3 to say only that putting stdlib.h in one of the
> angle-bracket places invokes UB.
I actually read it in exactly this way. I understood "the standard
places that are searched for included source files" as "angle-bracket
places". If it means something different, then I have no idea what
this paragraph says.
Regards,
Yevgen
Flash Gordon
It was indeed carefully constructed so that given an appropriate include
then you would have C code that compiles in to a C program.
> In case of original program using windows.h
> you *do* know what windows.h is, and you do know that's a C program.
> If you don't know what windows.h was, you can ask.
Others have pointed out that there is more than one header file called
windows.h which are there for different purposes. The ones provided by
MS has IIRC things which are not legal C syntax in them (the way calling
conventions etc are specified).
The code as presented was not C code. If it was presented with
appropriate headers then the complete set could be C code.
> And we get back to the fact that it's possible to say for sure
> if something is standard C or not only for complete program.
No, not a complete program, just enough if it to not rely on things
which are not C.
> Once you start saying
>
> int a = 2;
>
> or
>
> int func (void)
> {
> return 0;
> }
>
> is C code, you get away from the safe route (standardise) and get to
> area of "it looks and breathes like C", the stuff I am talking about.
>
> In other words, you are saying my "definition" (which I don't really
> have) is no good, and you just use another one, which is just as
> non-strict as mine. Then you can ignore the question about what
> "C programs" are since you can think about "C code" instead :)
I made some attempt to provide some kind of scope to what is and is not
C, although it is not perfect. You, on the other hand, just said that it
might be C even if it goes beyond what the standard defined and gave no
outer limit on what could be considered C. With no such limits then this
entire post is C because for all you know it could be an extract from a
file that has /* before what is shown here and closes the comment after.
So you have to put some limit on what you consider to be C code, you
don't have to make an attempt to tell us what it is, but if you don't
then don't complain when others express there opinion that something is
not C code.
>>> -----------------------------------------------------
>>>
>>> A long quote, but it was hard enough to write that, and I didn't
>>> try to edit/compress it.
>>
>> It does not address what you think is and is not C, it only says you
>> don't agree with C code being only code which is specified (possibly
>> as being implementation defined) by the C standard.
>
> I didn't discuss "C code" term at all. I can tell that it seems
> we have same ideas about what is C code and what isn't though.
I introduced it because in my opinion "is it C code?" is a far more
useful question than "is it a C program?"
<snip>
>>> How do you distinguish "C code" from "pseudo-C crap". As far as the
>>> standard is concerned, once you have any non-standard #include
>>> in your file, you get "pseudo-C crap".
>>
>> Only if the non-standard header is not provided or is not itself C
>> code. If the non-standard header has no impact on the rest of the file
>> then only that one line is "pseudo-C crap", if you don't know the
>> contents of the header then the entire presented code can validly be
>> considered as "pseudo-C crap".
You see, here I tightened up the definition up so that my earlier
example given on its own because "not C code".
>> > Once you have one file in
>>> your program which uses a non-standard feature (even if the other
>>> thousand files are perfect standard C), then the program is "pseudo-C
>>> crap". So the question stands. You like to write pseudo-C crap,
>>> it's fine; I still believe there are lot of C programmers writing
>>> C programs, which are C programs even if they use POSIX api, windows
>>> api, foobar api, etc.
>>
>> Personally since I started writing C hardly any programs I have
>> written have been C programs (or do yo consider " LAC *+,AR0" to be C?)
>
> It can't be made C even using preprocessor tricks, so it's not C at all.
> I guess.
The point was there is a program where 90% or more is completely
standard C. Then there are a few linker tricks to get some variables
which are only ever declared as "extern" in the C mapped on to some
hardware (so the C code is not having to do tricks like converting
integers to pointers to access memory mapped devices). Then there are
one or two assembler files making up under 10% of the code. So 90% is C
but a small fraction is not, and the status of the 90% as being C code
is far more important than the status of the program as a whole.
>> but I have written a lot of C code that has been incorporated with
>> other stuff to produce programs.
>>
>>> Somehow almost all programs on my computer are written in C. You
>>> may say they are written in "Pseudo-Unix pseudo-C crap", it's your
>>> choice. But it's not a sensible choice.
>>
>> A lot of programs are written mostly in C, but if the program as a
>> whole is not written in C then calling it a C program is misleading,
>> although saying it is mostly written in C is not.
>>
>> If I write a program with 25% assembler, 25% C, 25% Java and 25%
>> Fortran, what language is the program written in? My answer is "a
>> mixture".
>
> Yes, it's a mixture. But I wasn't talking about such cases. I was
> talking about programs which have 100% C code. Using non-standard
> features like "libraries" though.
Those libraries are written in something. If they are written in C then
expand your scope to include them and you have a C program (I use XML
libraries which are at least mostly written in C for example). However,
if either those extras are not C *or* you are not including them in what
you are presenting, then what you are presenting is no longer C but
C+whatever or Windows-C or POSIX-C.
Note that a header that is not part of standard C and is not provided as
part of what is presented could easily contain things which convert your
program from being valid C to being valid some-other-language. C is not
the only language to use #include! I would assume it was C+something but
I could not be completely convinced, because I do know that there are
files called windows.h which are nothing to do with MS Windows.
--
Flash Gordon
Flash Gordon
> Flash Gordon wrote:
> ... snip ...
>> If I write a program with 25% assembler, 25% C, 25% Java and 25%
>> Fortran, what language is the program written in? My answer is
>> "a mixture".
>
> Such a 'program' is not portable, since they depend on the
> mechanisms provided for linking, function calling, etc. It MAY
> work on some system that imposes the same requirements on the
> object files generated by each compiler. Since things are system
> dependent, they are not topical here. Even Ada, which has built-in
> provision for linking C code, depends on the compilation of the C
> with a compiler compatible with the Ada compiler.
I agree that it is not portable. I also say that whatever the
percentages are the *program* is a mixture although it may have any
amount of C code. For all we know the windows.h file could be providing
some non-portable interface to some user-written assembler code which is
far larger than the C code.
--
Flash Gordon
Yevgen Muntyan
Yeah, "others". Of course there are many windows.h files, I can write
about zillion more using my favorite shell. But the windows.h header was
a windows C api header. If you don't know that, just ask ;)
For instance, I knew it was *the* windows windows.h header because the
code was posted by one famous portable-code-writer comp.lang.c regular.
> The ones provided by
> MS has IIRC things which are not legal C syntax in them (the way calling
> conventions etc are specified).
If you mean things like __declspec, they are fine,
implementation-specific extensions. Program wasn't portable and nobody
said it was, so it's fine (and windows.h is indeed a part of
implementation). But the program itself used a nice #include
directive, which has well-defined (or rather well-understood and
well-agreed-on) semantics and the rest of code was real C code. A C
program.
Well, the standard does *not* define what is "C code". I understand
what you mean, you understand what you mean, but it's not what
standard says. Standard doesn't know what it means "N% of C code"
or "two lines of C code".
How about "C program is a program consisting of C code" anyway?
> With no such limits then this
> entire post is C because for all you know it could be an extract from a
> file that has /* before what is shown here and closes the comment after.
> So you have to put some limit on what you consider to be C code, you
> don't have to make an attempt to tell us what it is, but if you don't
> then don't complain when others express there opinion that something is
> not C code.
Yeah yeah, "opinion". Now do go back and read that very post, where
"others" "expressed their opinion". It wasn't "given that I have no
clue what windows.h I can't make a conclusion if it's C or not". No, it
was "fsking no, it's non-standard therefore not C", an emotional
response caused by feelings of one person to another one.
*If* someone was interested in that program he could ask what windows.h
was. If someone wasn't interested in it, he could ignore it. But "not
C because I pretend I have no clue what it is" is nonsense.
Oh well.
>>>> -----------------------------------------------------
>>>>
>>>> A long quote, but it was hard enough to write that, and I didn't
>>>> try to edit/compress it.
>>>
>>> It does not address what you think is and is not C, it only says you
>>> don't agree with C code being only code which is specified (possibly
>>> as being implementation defined) by the C standard.
>>
>> I didn't discuss "C code" term at all. I can tell that it seems
>> we have same ideas about what is C code and what isn't though.
>
> I introduced it because in my opinion "is it C code?" is a far more
> useful question than "is it a C program?"
>
> <snip>
>
>>>> How do you distinguish "C code" from "pseudo-C crap". As far as the
>>>> standard is concerned, once you have any non-standard #include
>>>> in your file, you get "pseudo-C crap".
>>>
>>> Only if the non-standard header is not provided or is not itself C
>>> code. If the non-standard header has no impact on the rest of the
>>> file then only that one line is "pseudo-C crap", if you don't know
>>> the contents of the header then the entire presented code can validly
>>> be considered as "pseudo-C crap".
>
> You see, here I tightened up the definition up so that my earlier
> example given on its own because "not C code".
You miss the important fact here. If you have a non-standard #include
in your C code, it may fail to be processed by a conforming C compiler.
Even if that header is empty, for instance. You are saying that it's
C code because reasonable compiler will indeed process it; or because
you can expand #include manually; or for whatever else reason. But the
standard doesn't agree. I, from the other hand, claim that it's totally
fine to say it's a C program (or C code if you prefer), even though
it's not standard.
>
>>> > Once you have one file in
>>>> your program which uses a non-standard feature (even if the other
>>>> thousand files are perfect standard C), then the program is "pseudo-C
>>>> crap". So the question stands. You like to write pseudo-C crap,
>>>> it's fine; I still believe there are lot of C programmers writing
>>>> C programs, which are C programs even if they use POSIX api, windows
>>>> api, foobar api, etc.
>>>
>>> Personally since I started writing C hardly any programs I have
>>> written have been C programs (or do yo consider " LAC *+,AR0" to be
>>> C?)
>>
>> It can't be made C even using preprocessor tricks, so it's not C at all.
>> I guess.
>
> The point was there is a program where 90% or more is completely
> standard C. Then there are a few linker tricks to get some variables
> which are only ever declared as "extern" in the C mapped on to some
> hardware (so the C code is not having to do tricks like converting
> integers to pointers to access memory mapped devices). Then there are
> one or two assembler files making up under 10% of the code. So 90% is C
> but a small fraction is not, and the status of the 90% as being C code
> is far more important than the status of the program as a whole.
I can't disagree here. Anyway, do you count #include <cheader.h> as
C code? As well as #include "cheader.h" (sure, provided the complete
listing of cheader.h is available, the standard doesn't say it will
help).
>>> but I have written a lot of C code that has been incorporated with
>>> other stuff to produce programs.
>>>
>>>> Somehow almost all programs on my computer are written in C. You
>>>> may say they are written in "Pseudo-Unix pseudo-C crap", it's your
>>>> choice. But it's not a sensible choice.
>>>
>>> A lot of programs are written mostly in C, but if the program as a
>>> whole is not written in C then calling it a C program is misleading,
>>> although saying it is mostly written in C is not.
>>>
>>> If I write a program with 25% assembler, 25% C, 25% Java and 25%
>>> Fortran, what language is the program written in? My answer is "a
>>> mixture".
>>
>> Yes, it's a mixture. But I wasn't talking about such cases. I was
>> talking about programs which have 100% C code. Using non-standard
>> features like "libraries" though.
>
> Those libraries are written in something. If they are written in C then
> expand your scope to include them and you have a C program (I use XML
> libraries which are at least mostly written in C for example).
"Expand scope", huh? If you include their source files, it's standard.
If you use linker, it becomes non-standard, i.e. just as standard-C
as embedded assembly. But the result is the same, the point is the same:
you have a C program (program consisting of C code if you prefer), you
use C headers.
> However,
> if either those extras are not C *or* you are not including them in what
> you are presenting, then what you are presenting is no longer C but
> C+whatever or Windows-C or POSIX-C.
>
> Note that a header that is not part of standard C and is not provided as
> part of what is presented could easily contain things which convert your
> program from being valid C to being valid some-other-language. C is not
> the only language to use #include! I would assume it was C+something but
> I could not be completely convinced, because I do know that there are
> files called windows.h which are nothing to do with MS Windows.
Well, I just made an (completely reasonable) assumption that the
windows.h thing was indeed *that* windows.h thing. You can have
reasonable doubt in it, since it may or may not have been that
windows.h. But can you just claim "not C" because I/he didn't tell
what windows.h was? Can you tell that "beep beep not C" is just
as reasonable as my "I believe it's C program which uses windows
api"?
Yevgen
Mark McIntyre
<muntyan.r...@tamu.edu> wrote:
>In case of original program using windows.h
>you *do* know what windows.h is, and you do know that's a C program.
This is where I disagree fairly strongly, and I've given evidence to
back my position elsethread, and a bit more below.
>If you don't know what windows.h was, you can ask.
see below !
>I was talking about programs which have 100% C code. Using non-standard
>features like "libraries" though.
unless the header for the library is entirely valid C, the programme
isn't strictly a C programme any more. The difficulty is that many
libraries of the type of win32, posix, curses etc do rely on
nonstandard and often downright inadmissible functionality.
For example, the Windows.h that came with MSVC 6.0 contains a 79
illegal or erroneous constructs eg:
winnt.h(357) : error C2467: illegal declaration of anonymous 'struct'
winnt.h(1519) : error C2054: expected '(' to follow '_inline'
winnt.h(1519) : error C2085: 'GetFiberData' : not in formal param list
winnt.h(1519) : error C2143: syntax error : missing ';' before '{'
winnt.h(4357) : error C2467: illegal declaration of anonymous 'union'
and even this gem:
cguid.h(54) : warning C4179: '//*' : parsed as '/' and '/*'
cguid.h(124) : fatal error C1071: unexpected end of file found in
comment
which is schoolboy error of hilarious proportions.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mark McIntyre
<muntyan.r...@tamu.edu> wrote:
>For instance, I knew it was *the* windows windows.h header because the
>code was posted by one famous portable-code-writer comp.lang.c regular.
Thats as may be, but "the" windows.h isn't a valid C header. See
elsethread.
Flash Gordon
> On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
> <muntyan.r...@tamu.edu> wrote:
>
>> In case of original program using windows.h
>> you *do* know what windows.h is, and you do know that's a C program.
>
> This is where I disagree fairly strongly, and I've given evidence to
> back my position elsethread, and a bit more below.
>
>> If you don't know what windows.h was, you can ask.
>
> see below !
>
>> I was talking about programs which have 100% C code. Using non-standard
>> features like "libraries" though.
>
> unless the header for the library is entirely valid C, the programme
> isn't strictly a C programme any more. The difficulty is that many
> libraries of the type of win32, posix, curses etc do rely on
> nonstandard and often downright inadmissible functionality.
Please note the above, Yevgen, this is not specifically anti MS, as Mark
points out it applies to Posix, curses etc.
> For example, the Windows.h that came with MSVC 6.0 contains a 79
> illegal or erroneous constructs eg:
>
> winnt.h(357) : error C2467: illegal declaration of anonymous 'struct'
> winnt.h(1519) : error C2054: expected '(' to follow '_inline'
> winnt.h(1519) : error C2085: 'GetFiberData' : not in formal param list
> winnt.h(1519) : error C2143: syntax error : missing ';' before '{'
> winnt.h(4357) : error C2467: illegal declaration of anonymous 'union'
>
>
> and even this gem:
> cguid.h(54) : warning C4179: '//*' : parsed as '/' and '/*'
> cguid.h(124) : fatal error C1071: unexpected end of file found in
> comment
>
> which is schoolboy error of hilarious proportions.
That's even worse that I was assuming! Very good Mark.
--
Flash Gordon
Another Mark on comp.lang.c
Flash Gordon
He does tend to get a more extreme reaction that a newbie would because
he knows the scope of the group but flouts it anyway.
>> The ones provided by MS has IIRC things which are not legal C syntax
>> in them (the way calling conventions etc are specified).
>
> If you mean things like __declspec, they are fine,
> implementation-specific extensions.
I agree that it is a valid way to do an extension, MS are actually quite
good in that respect. However, it violates the syntax of C because C
syntax does not allow adding anything at that point of a declaration.
Just to be clear, using __whatever to add it was doing the right thing.
> Program wasn't portable and nobody
> said it was, so it's fine (and windows.h is indeed a part of
> implementation). But the program itself used a nice #include
> directive, which has well-defined (or rather well-understood and
> well-agreed-on) semantics and the rest of code was real C code. A C
> program.
Given certain assumptions the C code was valid C code, however from what
I remember it certainly was not a C program solving the problem since it
not only relied on non-C APIs (the Windows API with comments showing a
suggested Unix alternative) but also relied on external programs that in
general are *not* installed on machine.
<anip>
>> I made some attempt to provide some kind of scope to what is and is
>> not C, although it is not perfect. You, on the other hand, just said
>> that it might be C even if it goes beyond what the standard defined
>> and gave no outer limit on what could be considered C.
>
> Well, the standard does *not* define what is "C code". I understand
> what you mean, you understand what you mean, but it's not what
> standard says. Standard doesn't know what it means "N% of C code"
> or "two lines of C code".
Well, the C standard does not know about anything that is *not* C code
so it does not have to make the distinction between C code and code that
is not C.
> How about "C program is a program consisting of C code" anyway?
A C program consists *only* of C code.
>> With no such limits then this entire post is C because for all you
>> know it could be an extract from a file that has /* before what is
>> shown here and closes the comment after. So you have to put some limit
>> on what you consider to be C code, you don't have to make an attempt
>> to tell us what it is, but if you don't then don't complain when
>> others express there opinion that something is not C code.
>
> Yeah yeah, "opinion". Now do go back and read that very post, where
> "others" "expressed their opinion". It wasn't "given that I have no
> clue what windows.h I can't make a conclusion if it's C or not".
If I remember the post correctly it relied on there being a C compiler
on the target, where generally there is not, and on the ability to
dynamically load executable (which is only common on hosted systems, but
probably not available on *all* hosted systems). So in this particular
case the bulk of what the program was assuming was actually system
specific (and available as much through any other language in the same
way) rather than being C. It was probably close to "replace { with
begin, } with END; and int main() with PROGRAM FRED;" and you would have
a Pascal program in the same sense that you are calling it a C program.
If hanging 10% changes it to another language, but getting it to run on
a different system means changing 90% then is it really a C solution?
> No, it
> was "fsking no, it's non-standard therefore not C", an emotional
> response caused by feelings of one person to another one.
> *If* someone was interested in that program he could ask what windows.h
> was. If someone wasn't interested in it, he could ignore it. But "not
> C because I pretend I have no clue what it is" is nonsense.
> Oh well.
Topicality is enforced to keep the experts here and so keep the group
valuable. Jacob gets extreme reactions because of how often he has
flouted topicality pushing either Windows specific code or his own
extensions to C.
<snip>
>>>>> How do you distinguish "C code" from "pseudo-C crap". As far as the
>>>>> standard is concerned, once you have any non-standard #include
>>>>> in your file, you get "pseudo-C crap".
>>>>
>>>> Only if the non-standard header is not provided or is not itself C
>>>> code. If the non-standard header has no impact on the rest of the
>>>> file then only that one line is "pseudo-C crap", if you don't know
>>>> the contents of the header then the entire presented code can
>>>> validly be considered as "pseudo-C crap".
>>
>> You see, here I tightened up the definition up so that my earlier
>> example given on its own because "not C code".
>
> You miss the important fact here. If you have a non-standard #include
> in your C code, it may fail to be processed by a conforming C compiler.
> Even if that header is empty, for instance.
In that extreme case, just provide the empty header as well and it can
safely be called C code.
> You are saying that it's
> C code because reasonable compiler will indeed process it; or because
> you can expand #include manually; or for whatever else reason. But the
> standard doesn't agree. I, from the other hand, claim that it's totally
> fine to say it's a C program (or C code if you prefer), even though
> it's not standard.
As far as I can see the standard only considers it to be C if it can be
compiled, so if it includes a header that does not exist then it is just
plain broken.
If you say "this header defines the prototypes for these non-standard
functions" then we can consider everything apart from those non-standard
functions as C.
I do not see a need to say that even an entire file is C or not C, this
is why I emphasise that it is the code that is C or not C since then you
can graduate it as finely as you need.
>>>> > Once you have one file in
>>>>> your program which uses a non-standard feature (even if the other
>>>>> thousand files are perfect standard C), then the program is "pseudo-C
>>>>> crap". So the question stands. You like to write pseudo-C crap,
>>>>> it's fine; I still believe there are lot of C programmers writing
>>>>> C programs, which are C programs even if they use POSIX api, windows
>>>>> api, foobar api, etc.
>>>>
>>>> Personally since I started writing C hardly any programs I have
>>>> written have been C programs (or do yo consider " LAC *+,AR0" to
>>>> be C?)
>>>
>>> It can't be made C even using preprocessor tricks, so it's not C at all.
>>> I guess.
>>
>> The point was there is a program where 90% or more is completely
>> standard C. Then there are a few linker tricks to get some variables
>> which are only ever declared as "extern" in the C mapped on to some
>> hardware (so the C code is not having to do tricks like converting
>> integers to pointers to access memory mapped devices). Then there are
>> one or two assembler files making up under 10% of the code. So 90% is
>> C but a small fraction is not, and the status of the 90% as being C
>> code is far more important than the status of the program as a whole.
>
> I can't disagree here. Anyway, do you count #include <cheader.h> as
> C code? As well as #include "cheader.h" (sure, provided the complete
> listing of cheader.h is available, the standard doesn't say it will
> help).
Given a reason to suppose that the C compiler will succeed (headers need
not actually be files) then yes, I would consider it to be a line of C code.
>>>> but I have written a lot of C code that has been incorporated with
>>>> other stuff to produce programs.
>>>>
>>>>> Somehow almost all programs on my computer are written in C. You
>>>>> may say they are written in "Pseudo-Unix pseudo-C crap", it's your
>>>>> choice. But it's not a sensible choice.
>>>>
>>>> A lot of programs are written mostly in C, but if the program as a
>>>> whole is not written in C then calling it a C program is misleading,
>>>> although saying it is mostly written in C is not.
>>>>
>>>> If I write a program with 25% assembler, 25% C, 25% Java and 25%
>>>> Fortran, what language is the program written in? My answer is "a
>>>> mixture".
>>>
>>> Yes, it's a mixture. But I wasn't talking about such cases. I was
>>> talking about programs which have 100% C code. Using non-standard
>>> features like "libraries" though.
>>
>> Those libraries are written in something. If they are written in C
>> then expand your scope to include them and you have a C program (I use
>> XML libraries which are at least mostly written in C for example).
>
> "Expand scope", huh? If you include their source files, it's standard.
Yes, because then it is just a number of additional C translation units.
> If you use linker, it becomes non-standard,
The linker has nothing to do with it. After all, when combining multiple
translation unites (which is allowed by C) you are linking!
> i.e. just as standard-C
> as embedded assembly.
<sigh> No, because everything is standard C! It matters not to me
whether I have written the XML library in C or whether someone else has.
If the library is in C and my code using it is in C then everything is
in C. However, if the library is in assembler (or I do not know it is C)
then what I have is C+XML-library rather than just C. If the XML library
is written in assembler then you can call it either C+XML-library or
C+assembler, your choice, if you do not know what the XML-library is
written in then all you can do is call it C+XML-library.
> But the result is the same, the point is the same:
> you have a C program (program consisting of C code if you prefer), you
> use C headers.
No, if the libraries I am reliant on are C (i.e. part of what is defined
by the standard as C or written in C, with this applied recursively)
then the program as a whole is C. If somewhere along the line you reach
something that is not C (i.e. not written in C or not part of the
standard C library) then the program as a whole is C+whatever-is-not-C
even though the headers describing the interface to the not-C may
themselves be C.
>> However, if either those extras are not C *or* you are not including
>> them in what you are presenting, then what you are presenting is no
>> longer C but C+whatever or Windows-C or POSIX-C.
>>
>> Note that a header that is not part of standard C and is not provided
>> as part of what is presented could easily contain things which convert
>> your program from being valid C to being valid some-other-language. C
>> is not the only language to use #include! I would assume it was
>> C+something but I could not be completely convinced, because I do know
>> that there are files called windows.h which are nothing to do with MS
>> Windows.
>
> Well, I just made an (completely reasonable) assumption that the
> windows.h thing was indeed *that* windows.h thing. You can have
> reasonable doubt in it, since it may or may not have been that
> windows.h. But can you just claim "not C" because I/he didn't tell
> what windows.h was? Can you tell that "beep beep not C" is just
> as reasonable as my "I believe it's C program which uses windows
> api"?
So you call it "C+Windows API" and I call it "Windows-C" (yes, I know
I've paraphrased you). That does not actually look like quite so far
apart. It is more that I and some others (particularly when dealing with
certain people who show repeated disregard for topicality) put more
emphasis on the "+Windows API", and even more so when almost every line
is either using the Windows API or setting things up to use the Windows API.
--
Flash Gordon
Yevgen Muntyan
True.
>>> The ones provided by MS has IIRC things which are not legal C syntax
>>> in them (the way calling conventions etc are specified).
>>
>> If you mean things like __declspec, they are fine,
>> implementation-specific extensions.
>
> I agree that it is a valid way to do an extension, MS are actually quite
> good in that respect. However, it violates the syntax of C because C
> syntax does not allow adding anything at that point of a declaration.
> Just to be clear, using __whatever to add it was doing the right thing.
I am not sure what you mean by this. Standard permits implementation
to use whatever fancy stuff it wants to, __whatever is totally legal
in the system headers. User code didn't contain anything like that,
and it's trivial to write windows.h header which would make the program
work everywhere, like declare the two non-standard functions used.
> > Program wasn't portable and nobody
>> said it was, so it's fine (and windows.h is indeed a part of
>> implementation). But the program itself used a nice #include
>> directive, which has well-defined (or rather well-understood and
>> well-agreed-on) semantics and the rest of code was real C code. A C
>> program.
>
> Given certain assumptions the C code was valid C code, however from what
> I remember it certainly was not a C program solving the problem since it
> not only relied on non-C APIs (the Windows API with comments showing a
> suggested Unix alternative) but also relied on external programs that in
> general are *not* installed on machine.
Oh yeah, the program didn't solve the problem, and didn't solve even
the problem it aimed to solve. We are talking about C/not C here,
not about what the program did. We can discuss the minimal program
including windows.h for that purpose, the program which simply
does nothing but returning 0 from main.
> <anip>
>
>>> I made some attempt to provide some kind of scope to what is and is
>>> not C, although it is not perfect. You, on the other hand, just said
>>> that it might be C even if it goes beyond what the standard defined
>>> and gave no outer limit on what could be considered C.
>>
>> Well, the standard does *not* define what is "C code". I understand
>> what you mean, you understand what you mean, but it's not what
>> standard says. Standard doesn't know what it means "N% of C code"
>> or "two lines of C code".
>
> Well, the C standard does not know about anything that is *not* C code
> so it does not have to make the distinction between C code and code that
> is not C.
I am not saying it has to do anything. I am saying your notion of
"C code" is as non-standard as what I imagine "C program" is.
In other words: your "C code" has the same value as my "C program"
as far as the standard is concerned, the zero value.
But if you talk humanish, then we can talk about "C code" or
"not C code" and will understand each other well.
>> How about "C program is a program consisting of C code" anyway?
>
> A C program consists *only* of C code.
I asked what you think about such a "definition". Of course
a C program consists only of C code. But C program doesn't
include headers it uses. Take a look at any set of standard
headers, you'll find lots of implementation-specific stuff.
They are secured by the standard, which says "you don't care
what's inside", but it applies as well to other headers provided
by the implementation, such as windows.h. It's *not* really
important what's inside, the important thing is that the header
is provided by implementation to be used in C programs.
And by the way, the syntax errors shown elsewhere prove exactly nothing.
windows.h is not portable, and not meant to be. It's part of
implementation. I can provide you with mingw headers which
actually will work with GCC (what was that compiler, by the way?).
They won't work with other compilers because they are made
for GCC. Then what, program using those headers (string.h for
instance) is not C?
>>> With no such limits then this entire post is C because for all you
>>> know it could be an extract from a file that has /* before what is
>>> shown here and closes the comment after. So you have to put some
>>> limit on what you consider to be C code, you don't have to make an
>>> attempt to tell us what it is, but if you don't then don't complain
>>> when others express there opinion that something is not C code.
>>
>> Yeah yeah, "opinion". Now do go back and read that very post, where
>> "others" "expressed their opinion". It wasn't "given that I have no
>> clue what windows.h I can't make a conclusion if it's C or not".
>
> If I remember the post correctly it relied on there being a C compileionr
> on the target, where generally there is not, and on the ability to
> dynamically load executable (which is only common on hosted systems, but
> probably not available on *all* hosted systems). So in this particular
> case the bulk of what the program was assuming was actually system
> specific (and available as much through any other language in the same
> way) rather than being C. It was probably close to "replace { with
> begin, } with END; and int main() with PROGRAM FRED;" and you would have
> a Pascal program in the same sense that you are calling it a C program.
> If hanging 10% changes it to another language, but getting it to run on
> a different system means changing 90% then is it really a C solut?
Yes, it is. It's called "not portable". It's called "conforming but
not strictly conforming". You all the time talk about those BEGIN
and END things, to amplify my claim that non-standard things are
still C. But again, what do you think about #include "something.h"? It's
*not* standard C. I am rather saying that if program looks like
C, then it's likely to be C, and if C compilers can compile it, then
it's C. You are saying same thing, but you prefer to talk about lines of
code, or about precents or something.
Either you use standard language, i.e. you stick to calling "C"
only strictly conforming programs, or you invent more human things,
like your "C code" or my "C program". And these human things are
different only as coding styles differ.
> > No, it
>> was "fsking no, it's non-standard therefore not C", an emotional
>> response caused by feelings of one person to another one.
>> *If* someone was interested in that program he could ask what windows.h
>> was. If someone wasn't interested in it, he could ignore it. But "not
>> C because I pretend I have no clue what it is" is nonsense.
>> Oh well.
>
> Topicality is enforced to keep the experts here and so keep the group
> valuable. Jacob gets extreme reactions because of how often he has
> flouted topicality pushing either Windows specific code or his own
> extensions to C.
It's true, indeed.
> <snip>
>
>>>>>> How do you distinguish "C code" from "pseudo-C crap". As far as the
>>>>>> standard is concerned, once you have any non-standard #include
>>>>>> in your file, you get "pseudo-C crap".
>>>>>
>>>>> Only if the non-standard header is not provided or is not itself C
>>>>> code. If the non-standard header has no impact on the rest of the
>>>>> file then only that one line is "pseudo-C crap", if you don't know
>>>>> the contents of the header then the entire presented code can
>>>>> validly be considered as "pseudo-C crap".
>>>
>>> You see, here I tightened up the definition up so that my earlier
>>> example given on its own because "not C code".
>>
>> You miss the important fact here. If you have a non-standard #include
>> in your C code, it may fail to be processed by a conforming C compiler.
>> Even if that header is empty, for instance.
>
> In that extreme case, just provide the empty header as well and it can
> safely be called C code.
One more time: a program which has non-standard #include directive
is not strictly-conforming, i.e. not a C program according to
what you're saying. It's not a joke, check out comp.std.c for instance.
Even if your header is empty, the program isn't strictly conforming.
And it's not C? No way! It is C, I know that, you know that.
You have an escape here of course, you can say that all the lines
but the #include ones are "C code". I prefer not to employ such
tricks, I just honestly say that it's still a C program even if
not strictly conforming.
>
> > You are saying that it's
>> C code because reasonable compiler will indeed process it; or because
>> you can expand #include manually; or for whatever else reason. But the
>> standard doesn't agree. I, from the other hand, claim that it's totally
>> fine to say it's a C program (or C code if you prefer), even though
>> it's not standard.
>
> As far as I can see the standard only considers it to be C if it can be
> compiled, so if it includes a header that does not exist then it is just
> plain broken.
>
> If you say "this header defines the prototypes for these non-standard
> functions" then we can consider everything apart from those non-standard
> functions as C.
>
> I do not see a need to say that even an entire file is C or not C, this
> is why I emphasise that it is the code that is C or not C since then you
> can graduate it as finely as you need.
This is the part why we disagree, I think. You don't need to say if
some file is C or not. I do, I prefer to call C programs C programs,
not "something which includes some amount of C code" (I prefer to use
the latter for those programs which use GCC extensions, assembly,
C++, other stuff like that).
Well, it's a line which makes the program to be not strictly conforming.
Absolutely fine for me, I accept even more non-standard stuff in C
programs ;)
>>>>> but I have written a lot of C code that has been incorporated with
>>>>> other stuff to produce programs.
>>>>>
>>>>>> Somehow almost all programs on my computer are written in C. You
>>>>>> may say they are written in "Pseudo-Unix pseudo-C crap", it's your
>>>>>> choice. But it's not a sensible choice.
>>>>>
>>>>> A lot of programs are written mostly in C, but if the program as a
>>>>> whole is not written in C then calling it a C program is
>>>>> misleading, although saying it is mostly written in C is not.
>>>>>
>>>>> If I write a program with 25% assembler, 25% C, 25% Java and 25%
>>>>> Fortran, what language is the program written in? My answer is "a
>>>>> mixture".
>>>>
>>>> Yes, it's a mixture. But I wasn't talking about such cases. I was
>>>> talking about programs which have 100% C code. Using non-standard
>>>> features like "libraries" though.
>>>
>>> Those libraries are written in something. If they are written in C
>>> then expand your scope to include them and you have a C program (I
>>> use XML libraries which are at least mostly written in C for example).
>>
>> "Expand scope", huh? If you include their source files, it's standard.
>
> Yes, because then it is just a number of additional C translation units.
>
>> If you use linker, it becomes non-standard,
>
> The linker has nothing to do with it. After all, when combining multiple
> translation unites (which is allowed by C) you are linking!
Yep. Now tell you are compiling xml library sources with your program.
I doubt that, you most likely use the library, use a linker to get
symbols from it in a non-standard way. And as long as there are #include
directives, it's all not strictly conforming. Funny, isn't it?
*You* are saying your program is not C, I think it is C (as long as
you don't have C++ or something inside).
>
> > i.e. just as standard-C
>> as embedded assembly.
>
> <sigh> No, because everything is standard C! It matters not to me
> whether I have written the XML library in C or whether someone else has.
> If the library is in C and my code using it is in C then everything is
> in C.
Standard doesn't say this. It says that C files are C. If you process
those C files to get libxml.so and later use this libxml.so, you get
out of scope of the standard. *I understand* what you mean here,
but as far as the standard is concerned, what you are doing is no
more standard as embedded assembly (i.e. not standard).
(I presume you are using the library here)
> However, if the library is in assembler (or I do not know it is C)
> then what I have is C+XML-library rather than just C. If the XML library
> is written in assembler then you can call it either C+XML-library or
> C+assembler, your choice, if you do not know what the XML-library is
> written in then all you can do is call it C+XML-library.
>
> > But the result is the same, the point is the same:
>> you have a C program (program consisting of C code if you prefer), you
>> use C headers.
>
> No, if the libraries I am reliant on are C (i.e. part of what is defined
> by the standard as C or written in C, with this applied recursively)
> then the program as a whole is C.
See, you are no less creative than me in getting over the standard
to call something C ;)
Well, it was indeed a stupid idea to "defend" Jacob Navia. But it's
not only him who gets these stupid "not C period". And usually some
people find ways to put him down without resorting to such senseless
things like "beep beep not C".
> put more
> emphasis on the "+Windows API", and even more so when almost every line
> is either using the Windows API or setting things up to use the Windows
> API.
"+Windows API" is totally good, if it means "a C code which uses windows
api". And it's not about windows, by the way. I don't care much about
this crap. What I do care about is bunch of utilities in my /bin folder,
almost all of which are written in C. Even if none of them is written
in standard C (and mind you, without any assembly or something, single
#include <config.h> makes them non-standard).
Yevgen
Yevgen Muntyan
> On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
> <muntyan.r...@tamu.edu> wrote:
>
>> In case of original program using windows.h
>> you *do* know what windows.h is, and you do know that's a C program.
>
> This is where I disagree fairly strongly, and I've given evidence to
> back my position elsethread, and a bit more below.
Evidence of what, that you didn't know what windows.h was? You did
say there are many windows.h headers, and I am still claiming you
knew very well that windows.h in JN's code was the windows api
header. I can't prove it of course, and you can tell I am wrong,
sure.
>> If you don't know what windows.h was, you can ask.
>
> see below !
>
>> I was talking about programs which have 100% C code. Using non-standard
>> features like "libraries" though.
>
> unless the header for the library is entirely valid C, the programme
> isn't strictly a C programme any more. The difficulty is that many
> libraries of the type of win32, posix, curses etc do rely on
> nonstandard and often downright inadmissible functionality.
Come on, standard headers use same non-standard stuff. They are
protected by the standard which says "you don't care what's inside
the string.h", but nevertheless implementation is also free to
use any non-standard stuff in its own headers. windows.h is part
of particular implementation.
Take a look at glibc headers. string.h and regex.h are no different
in what's inside. Same load of __foobar and __attribute__. So a
program using <regex.h> isn't C, right?
> For example, the Windows.h that came with MSVC 6.0 contains a 79
> illegal or erroneous constructs eg:
>
> winnt.h(357) : error C2467: illegal declaration of anonymous 'struct'
> winnt.h(1519) : error C2054: expected '(' to follow '_inline'
> winnt.h(1519) : error C2085: 'GetFiberData' : not in formal param list
> winnt.h(1519) : error C2143: syntax error : missing ';' before '{'
> winnt.h(4357) : error C2467: illegal declaration of anonymous 'union'
You snipped some stuff, didn't you? C and C++ compilers are famous
by very sane error messages which follow the first, real one.
> and even this gem:
> cguid.h(54) : warning C4179: '//*' : parsed as '/' and '/*'
> cguid.h(124) : fatal error C1071: unexpected end of file found in
> comment
>
> which is schoolboy error of hilarious proportions.
Sure, MS makes schoolboy errors. Man, take any standard headers
of any implementation, and try to use them with another implementation
which wasn't intentionally made compatible with the first one (like
icc which pretends it's gcc, or like mingw which is both gcc and
accepting-windows-headers).
I did *not* say the program was strictly conforming. It surely
was not portable. You illustrate its non-portability by trying
to compile something which isn't intended to be compiled in
the way you did it. But why? It's non-portable from the start,
simply because it uses non-standard header.
Let's look at another thing, here on my linux:
muntyan@munt10:/tmp$ cat file.c
#include <windows.h>
int main(void)
{
return 0;
}
muntyan@munt10:/tmp$ gcc -I/usr/i586-mingw32msvc/include/ file.c
muntyan@munt10:/tmp$ icc -X -I/usr/i586-mingw32msvc/include/
-I/usr/lib/gcc/i586-mingw32msvc/3.4.5/include/ file.c
muntyan@munt10:/tmp$
See, it does compile. Mingw has nice headers and Microsoft has
shitty headers which work only with their compiler? Perhaps. So what?
We are not discussing quality of microsoft implementation,
we are discussing a C program which uses that silly windows
api. It's the *same program*, and it is a *C program*. Note I am
not claiming it's a portable program because I can compile
it or something; I am not using your "oops I made it not compile"
trick, just demonstrating that your demonstration was nothing.
Any not strictly conforming program can fail to compile with
some compiler (just by definition), and you showed it. So?
Yevgen
Kenny McCormack
Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>Mark McIntyre wrote:
>> On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
>> <muntyan.r...@tamu.edu> wrote:
>>
>>> In case of original program using windows.h
>>> you *do* know what windows.h is, and you do know that's a C program.
>>
>> This is where I disagree fairly strongly, and I've given evidence to
>> back my position elsethread, and a bit more below.
>
>Evidence of what, that you didn't know what windows.h was? You did
>say there are many windows.h headers, and I am still claiming you
>knew very well that windows.h in JN's code was the windows api
>header. I can't prove it of course, and you can tell I am wrong,
>sure.
You do realize, don't you, that you are arguing with idiots?
These are people who will never admit that the emperor has no clothes.
No matter how much common sense you throw at them.
Flash Gordon
> Flash Gordon wrote:
>> Yevgen Muntyan wrote, On 24/02/07 11:21:
<snip>
>>> How about "C program is a program consisting of C code" anyway?
>>
>> A C program consists *only* of C code.
>
> I asked what you think about such a "definition".
Perhaps I should have been clearer. What I think of your suggestion was
that it should be amended to what I provided o be clearer.
<snip>
>> If you say "this header defines the prototypes for these non-standard
>> functions" then we can consider everything apart from those
>> non-standard functions as C.
>>
>> I do not see a need to say that even an entire file is C or not C,
>> this is why I emphasise that it is the code that is C or not C since
>> then you can graduate it as finely as you need.
>
> This is the part why we disagree, I think. You don't need to say if
> some file is C or not. I do, I prefer to call C programs C programs,
> not "something which includes some amount of C code" (I prefer to use
> the latter for those programs which use GCC extensions, assembly,
> C++, other stuff like that).
I agree that this is probably the heart of our disagreement, so I've
snipped a lot of other parts where we still disagree.
My position is probably coloured by me experience. I have often been in
the position where I an effectively writing code to extend the
implementation and writing programs to make use of the code I wrote to
extend the implementations. Therefore, I am writing those headers (which
in my case generally are standard C) and the whatever-is-not-C as well,
or sometimes just porting a not-C library to some other system because I
need it to make my code work there. It is possibly because of this that
I consider calling MyFancyApi() you are leaving the realms of C since I
would actually write MyFancyApi() in assembler or whatever.
<snip>
>>> I can't disagree here. Anyway, do you count #include <cheader.h> as
>>> C code? As well as #include "cheader.h" (sure, provided the complete
>>> listing of cheader.h is available, the standard doesn't say it will
>>> help).
>>
>> Given a reason to suppose that the C compiler will succeed (headers
>> need not actually be files) then yes, I would consider it to be a line
>> of C code.
>
> Well, it's a line which makes the program to be not strictly conforming.
> Absolutely fine for me, I accept even more non-standard stuff in C
> programs ;)
I never said strictly conforming :-)
Note that I consider it to still be C code when it depends on
implementation defined behaviour for its output and that makes it no
longer strictly conforming. Even more, I would call "i = ++i;" incorrect
C rather than not C.
<snip>
>>>>>> If I write a program with 25% assembler, 25% C, 25% Java and 25%
>>>>>> Fortran, what language is the program written in? My answer is "a
>>>>>> mixture".
>>>>>
>>>>> Yes, it's a mixture. But I wasn't talking about such cases. I was
>>>>> talking about programs which have 100% C code. Using non-standard
>>>>> features like "libraries" though.
>>>>
>>>> Those libraries are written in something. If they are written in C
>>>> then expand your scope to include them and you have a C program (I
>>>> use XML libraries which are at least mostly written in C for example).
>>>
>>> "Expand scope", huh? If you include their source files, it's standard.
>>
>> Yes, because then it is just a number of additional C translation units.
>>
>>> If you use linker, it becomes non-standard,
>>
>> The linker has nothing to do with it. After all, when combining
>> multiple translation unites (which is allowed by C) you are linking!
>
> Yep. Now tell you are compiling xml library sources with your program.
It depends. On some systems the versions I want are available, so I
don't compile them, on some systems they are either not available at the
version I want ot not available, so I do compile them. When I compile
them I also get the support department where I work to ship them to the
customers and install them!
> I doubt that, you most likely use the library, use a linker to get
> symbols from it in a non-standard way. And as long as there are #include
> directives, it's all not strictly conforming. Funny, isn't it?
> *You* are saying your program is not C, I think it is C (as long as
> you don't have C++ or something inside).
Since I am using a library (which I compiled) written in standard C and
the rest of the applciation is standard C if you include the source code
for the library (which I did not write but did compile) then it is
strictly conforming. If, however, I sent it to someone without the
source for the library they could correctly say it is not strictly
conforming since it depends on things outside the C language which are
not part of what I provide.
By the way, I would say that most of my programs are not C but
C+whatever because they in general do depend on things beyond C since
they need to do things you cannot do with only C. I'm just ignoring
those parts of the programs for this discussion. :-)
>> > i.e. just as standard-C
>>> as embedded assembly.
>>
>> <sigh> No, because everything is standard C! It matters not to me
>> whether I have written the XML library in C or whether someone else
>> has. If the library is in C and my code using it is in C then
>> everything is in C.
>
> Standard doesn't say this. It says that C files are C. If you process
> those C files to get libxml.so and later use this libxml.so, you get
> out of scope of the standard.
No, if I do that and then post the code here *including* the C code used
to create libxml, then everyone will be happy that it is C (assuming no
other problems).
If, on the other hand, I only provide the code that *uses* libxml and
say, oh, that is just the standard XML functions provided by the
library) then I am not posting C but C+XML-library
> *I understand* what you mean here,
> but as far as the standard is concerned, what you are doing is no
> more standard as embedded assembly (i.e. not standard).
> (I presume you are using the library here)
No, it is very different from embedded assembly. If it is embedded
assembly then even if I post everything it is still C+embedded-assembly,
where as if I post the code to the XML library as well as the code using
it then it is once again standard C.
<snip>
>> > But the result is the same, the point is the same:
>>> you have a C program (program consisting of C code if you prefer), you
>>> use C headers.
>>
>> No, if the libraries I am reliant on are C (i.e. part of what is
>> defined by the standard as C or written in C, with this applied
>> recursively) then the program as a whole is C.
>
> See, you are no less creative than me in getting over the standard
> to call something C ;)
The difference is I am actually putting some kind of limits on what is
C. With your definition you could call a program written in C++ using
the STL a C program because it is just C+extensions. So are you going to
suggest a definition that will make what is definitely C++ something
other than C or not? If not, then as far as I can see your suggestion is
of no use. I may be being creative beyond what the standard says, but at
least I have made some attempt to provide something that excludes C++
from being C and can be of some use.
<snip>
>> put more emphasis on the "+Windows API", and even more so when almost
>> every line is either using the Windows API or setting things up to use
>> the Windows API.
>
> "+Windows API" is totally good, if it means "a C code which uses windows
> api". And it's not about windows, by the way. I don't care much about
> this crap. What I do care about is bunch of utilities in my /bin folder,
> almost all of which are written in C. Even if none of them is written
> in standard C (and mind you, without any assembly or something, single
> #include <config.h> makes them non-standard).
If you don't mind "+Windows API" or "+POSIX" etc then here we reach a
sensible compromise. I'm not bothered precisely how people interpret the
+whatever (is it the call to the API, or is it when the program actually
starts executing code within the API that it crosses the border, or
whatever), as long as they accept that it is not *just* C but C+whatever.
Of course, others on the group might not accept it ;-)
As I also said, you have not actually said where you draw the line, and
it is a line that needs to be drawn somewhere. Otherwise you can call
all C++ code C because it *is* just C+extensions, since that is the way
C++ was developed!
--
Flash Gordon
Yevgen Muntyan
Quoting myself:
-----
For instance, a C program which uses POSIX regex to work with
some strings, or a program which uses windows API to print list of
processes, are C programs as long as they don't use some fancy
non-C syntax or mechanics (insert "semantics" here).
-----
C++ code like std::foo(bar) or foo<bar> isn't C. You may think I think
it is C, but I did say it's not. I *can't* say where I draw that line,
simply because it's too hard, hard to formulate it in clear English
(hard even in native language). My original claim was (and still is,
what we arguing about is rather not-so-important details): set of C
programs is strictly greater than the set of strictly conforming C
programs. I dislike that you are not calling most C programs "C
programs", but your terminology is still quite sensible, because it
actually carries the information about what is from what and from where.
And you do accept the idea of "not every line of C code is a line of
strictly conforming program", so we're in fact in agreement.
Yevgen
Beej
undefined behavior is "correct" (and shall act in accordance with
section 5.1.2.3, Program Execution.)
I don't believe the the standard makes any statements concerning "just
C" or "C plus extensions", or "is C" or "is not C". You're even going
to be hard pressed to find the words "standard C" in the standard.
But never mind all that. The definitions of "correct" and "strictly
conforming" should cover all cases, right?
The degree to which you guys are willing to discuss non-conforming
code on clc, well, that's a different matter. :-)
-Beej
Yevgen Muntyan
> My read of Chapter 4 is that a program that does not implement any
> undefined behavior is "correct" (and shall act in accordance with
> section 5.1.2.3, Program Execution.)
>
> I don't believe the the standard makes any statements concerning "just
> C" or "C plus extensions", or "is C" or "is not C". You're even going
> to be hard pressed to find the words "standard C" in the standard.
Of course.
> But never mind all that. The definitions of "correct" and "strictly
> conforming" should cover all cases, right?
It doesn't cover the following thing (not "program", it's what we
are arguing about):
two files, file.h and file.c:
file.h: empty;
file.c:
------------------
#include "file.h"
int main (void)
{
return 0;
}
Still, most people here agree it's a C program, or C code, "C"
in short.
> The degree to which you guys are willing to discuss non-conforming
> code on clc, well, that's a different matter. :-)
Nobody is discussing non-conforming code. We are discussing what
*conforming* code may be called "C". The following is conforming:
#include <windows.h>
int main (void)
{
return 0;
}
Yevgen
Beej
wrote:
> Nobody is discussing non-conforming code. We are discussing what
> *conforming* code may be called "C".
Ah. My mistake. Carry on. :)
-Beej
Flash Gordon
<snip>
> C++ code like std::foo(bar) or foo<bar> isn't C. You may think I think
> it is C, but I did say it's not. I *can't* say where I draw that line,
> simply because it's too hard, hard to formulate it in clear English
> (hard even in native language).
Yes, I have a rather large advantage over you their. For someone who is
not a native English speaker you do very well.
> My original claim was (and still is,
> what we arguing about is rather not-so-important details): set of C
> programs is strictly greater than the set of strictly conforming C
> programs. I dislike that you are not calling most C programs "C
> programs", but your terminology is still quite sensible, because it
> actually carries the information about what is from what and from where.
> And you do accept the idea of "not every line of C code is a line of
> strictly conforming program", so we're in fact in agreement.
OK, I think we can agree to disagree on where the line is drawn. As you
say this is not the most important thing.
--
Flash Gordon
Mark McIntyre
<muntyan.r...@tamu.edu> wrote:
>Mark McIntyre wrote:
>> On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
>> <muntyan.r...@tamu.edu> wrote:
>>
>>> In case of original program using windows.h
>>> you *do* know what windows.h is, and you do know that's a C program.
>>
>> This is where I disagree fairly strongly, and I've given evidence to
>> back my position elsethread, and a bit more below.
>
>Evidence of what, that you didn't know what windows.h was?
No, that its not a C programme.
>I am still claiming you knew very well that windows.h in JN's code was the windows api
I see, you can read my thoughts...
>
>> For example, the Windows.h that came with MSVC 6.0 contains a 79
>> illegal or erroneous constructs eg:
>>
>> winnt.h(357) : error C2467: illegal declaration of anonymous 'struct'
>> winnt.h(1519) : error C2054: expected '(' to follow '_inline'
>> winnt.h(1519) : error C2085: 'GetFiberData' : not in formal param list
>> winnt.h(1519) : error C2143: syntax error : missing ';' before '{'
>> winnt.h(4357) : error C2467: illegal declaration of anonymous 'union'
>
>You snipped some stuff, didn't you?
Yes, I snipped the other 74 errors.
>C and C++ compilers are famous
>by very sane error messages which follow the first, real one.
I see - you think I disengenuously forged the error messages by hiding
the real one. Think again, and perhaps even try this yourself.
Remember to disable language extensions.
>take any standard headers
>of any implementation, and try to use them with another implementation
>which wasn't intentionally made compatible with the first one (like
>icc which pretends it's gcc, or like mingw which is both gcc and
>accepting-windows-headers).
Fascinating. However I was compiling the MSVC6.0 version of windows.h
with... wait for it.... MSVC6.0.
>We are not discussing quality of microsoft implementation,
>we are discussing a C program which uses that silly windows
>api. It's the *same program*, and it is a *C program*.
Actually, you're now proving my point - it *becomes* a C programme,
provided the contents of windows.h are valid C. This is the crux of
the matter. Unless you know whats in that, you can only say that it
*may* be a C programme.
Mark McIntyre
<muntyan.r...@tamu.edu> wrote:
>It doesn't cover the following thing (not "program", it's what we
>are arguing about):
For the record, the below is *NOT* what we're arguing about.
>two files, file.h and file.c:
>
>file.h: empty;
>file.c:
>------------------
>#include "file.h"
>int main (void)
>{
> return 0;
>}
>
>Still, most people here agree it's a C program, or C code, "C"
>in short.
The above /is/ C, since the contents of file.h are known and are valid
C. This differs from the example with windows.h since we don't know
the content (and in fact I've proved elsethread that the one file we
thought it might have been isn't valid C).
Yevgen Muntyan
> On Sun, 25 Feb 2007 10:18:31 GMT, in comp.lang.c , Yevgen Muntyan
> <muntyan.r...@tamu.edu> wrote:
>
>> It doesn't cover the following thing (not "program", it's what we
>> are arguing about):
>
> For the record, the below is *NOT* what we're arguing about.
>
>> two files, file.h and file.c:
>>
>> file.h: empty;
>> file.c:
>> ------------------
>> #include "file.h"
>> int main (void)
>> {
>> return 0;
>> }
>>
>> Still, most people here agree it's a C program, or C code, "C"
>> in short.
>
> The above /is/ C, since the contents of file.h are known and are valid
> C. This differs from the example with windows.h since we don't know
> the content (and in fact I've proved elsethread that the one file we
> thought it might have been isn't valid C).
Um, and I proved elsethread that it's been valid C by compiling
it with gcc and icc? Funny.
Anyway, you're saying the above is valid C. Why? The standard
doesn't say it is. This program relies on implementation-defined
ways to process #include directives. It's not strictly conforming.
It is conforming. How *much* is it different from a program which
uses windows.h, a header file which is part of certain implementation?
I.e. how do you define that something not standard is C, and something
isn't? I apply common sense, you?
As far as standard is concerned, they are the same. Both conforming,
and both not strictly conforming. Now we can talk about what "is C"
and what is "pseudo C crap" or something, and it's what we are arguing
about. But you can't *prove* anything here by compiling/miscompiling
something (something which is part of implementation, like string.h,
which isn't required to be standard C code).
For the record, this file.c and file.h program is of course C.
Yevgen
Richard Bos
> Beej Jorgensen <be...@beej.us> writes:
> > 7.1.2 paragraph 3:
> >
> > If a file with the same name as one of the above < and > delimited
> > sequences, not provided as part of the implementation, is placed in
> > any of the standard places that are searched for included source
> > files, the behavior is undefined.
>
> Interesting. That says that if I place a "stdlib.h" file in one of
> the places searched for a
> #include "stdlib.h"
> directive but *not* for a
> #include <stdlib.h>
> directive, then the behavior is undefined. I suspect that wasn't the
> intent.
I suspect that the intent was that if you place a new stdlib.h in one of
the <> places, you're effectively creating a new C _implementation_, not
a new C source program. If you place a stdlib.h in one of the "" places,
you're doing the latter, trying to create a different program in C, but
one that has undefined behaviour.
Richard
Keith Thompson
I don't see any reason for the latter to have UB other than the fact
that 7.1.2p3 explicitly says so (or seems to). If I create a file
stdlib.h in one of the "" places, and my program has
#include <stdlib.h>
then the compiler should never even look at the stdlib.h I created.
Dik T. Winter
I think the intent was that when the compiler recognises the name of a
standard include file it is allowed to act accordingly.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Yevgen Muntyan
> In article <45e2a421....@news.xs4all.nl> r...@hoekstra-uitgeverij.nl (Richard Bos) writes:
> > Keith Thompson <ks...@mib.org> wrote:
> > > Beej Jorgensen <be...@beej.us> writes:
> > > > 7.1.2 paragraph 3:
> > > >
> > > > If a file with the same name as one of the above < and > delimited
> > > > sequences, not provided as part of the implementation, is placed in
> > > > any of the standard places that are searched for included source
> > > > files, the behavior is undefined.
> > >
> > > Interesting. That says that if I place a "stdlib.h" file in one of
> > > the places searched for a
> > > #include "stdlib.h"
> > > directive but *not* for a
> > > #include <stdlib.h>
> > > directive, then the behavior is undefined. I suspect that wasn't the
> > > intent.
> >
> > I suspect that the intent was that if you place a new stdlib.h in one of
> > the <> places, you're effectively creating a new C _implementation_, not
> > a new C source program. If you place a stdlib.h in one of the "" places,
> > you're doing the latter, trying to create a different program in C, but
> > one that has undefined behaviour.
>
> I think the intent was that when the compiler recognises the name of a
> standard include file it is allowed to act accordingly.
Below is the quote from comp.std.c thread about #include:
Douglas A. Gwyn wrote:
> "Yevgen Muntyan" <muntyan.r...@tamu.edu> wrote...
[snip]
>> ? Or "string.h", what if implementation treats
>> #include "string.h"
>> as
>> #include <string.h>
>
> It is supposed to apply its defined search rules first, and only if not
> found in that search should it use the standard header. Note that it
> is a useful programming practice for portability to use "" instead of
> <> for standard headers, since it makes it possible to substitute
> application-provided replacements when necessary to compensate
> for problems in the implementation-provided headers, without
> affecting the system files.
It'd be not so nice if this "useful programming practice" actually
relied on undefined behavior. But then, another quote:
Jun Woong wrote:
> genn...@invalid.address.com wrote:
> [...]
>> * #include "stdio.h"
>>
>> would search for a source file first, if the search is supported;
>> if it is not, or if the search fails, it is processed as if it were
>>
>> #include <stdio.h>
>>
>
> Unless #include "stdio.h" triggers the undefined behavior.
Apparently it's one more nice topic for comp.std.c, without
answers thanks to nice wording in the standard ;)
Yevgen
Mark McIntyre
<muntyan.r...@tamu.edu> wrote:
>> the content (and in fact I've proved elsethread that the one file we
>> thought it might have been isn't valid C).
>
>Um, and I proved elsethread that it's been valid C by compiling
>it with gcc and icc? Funny.
As I'm sure you're aware, if you can find one counterexample it
disproves a theory. Any number of examples which match the theoretical
outcome are useless.
>Anyway, you're saying the above is valid C. Why? The standard
>doesn't say it is.
I disagree, but now you're picking at nonexistent nits and engaging in
disingenuous and absurd arguments, and have become a troll.
>For the record, this file.c and file.h program is of course C.
Agreed.
Yevgen Muntyan
> On Sun, 25 Feb 2007 23:32:05 GMT, in comp.lang.c , Yevgen Muntyan
> <muntyan.r...@tamu.edu> wrote:
>
>>> the content (and in fact I've proved elsethread that the one file we
>>> thought it might have been isn't valid C).
>> Um, and I proved elsethread that it's been valid C by compiling
>> it with gcc and icc? Funny.
>
> As I'm sure you're aware, if you can find one counterexample it
> disproves a theory. Any number of examples which match the theoretical
> outcome are useless.
Your counterexample shows what? That you can make your compiler
miscompile its own header? I'd say it's not an obvious proof
of "the header isn't C". In any case, *the program which uses
the header* is C (that program, not any, not always).
We could talk about version of your compiler, about version
of my compiler which I use with <windows.h> header, about
non-conforming Microsoft implementation, about possibility to make
up that header without using non-standard stuff so that the program
still has the same meaning, about standard headers of whatever-you-like
compiler and "proving" they are not C, but you don't want to, right?
You simply mistreated some piece of soft you have there and tell
it's a "proof".
>> Anyway, you're saying the above is valid C. Why? The standard
>> doesn't say it is.
>
> I disagree, but now you're picking at nonexistent nits and engaging in
> disingenuous and absurd arguments,
Um, in what part exactly? Could you check the thread in comp.std.c
about the #include? I wouldn't say that's a 100% proof of something,
but I do believe it's not just nonexistent nits. *I* claim that
a C program need not to be strictly conforming. *You* do not agree
with this, and at the same time you do not agree to use strictest
definition, the strictly conforming program notion, you simply
can't afford that since you'd end up with writing in "beep beep"
language instead of C. So what's C? What you're saying and thinking it
is? I wouldn't object, if you admitted that. But you don't, you think
your opinion is from gods or from standard or something, and mine is
junk.
> and have become a troll.
I thought trolling is "beep beep not C".
Yevgen
Mark McIntyre
<muntyan.r...@tamu.edu> wrote:
>Your counterexample shows what?
That when you force MSVC into ISO mode, it can't compile its own
header without errors.
>I'd say it's not an obvious proof of "the header isn't C".
Then you are plainly an idiot.
I believe we're done here. Nothing further need be said.