Automatically generate variables

[Yevgen Muntyan]

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).

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 ...

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.

 

[Keith Thompson]

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).

 

[Flash Gordon]

Yevgen Muntyan wrote, On 23/02/07 13:33:

Well, since it's indeed hard to read, and much easier just to pick
some words and argue about them, I'll quote myself:

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!

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.

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".

 

[Beej Jorgensen]

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]

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".

 

[Beej Jorgensen]

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 ...

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]

Yevgen Muntyan wrote, On 23/02/07 13:33:



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.

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.

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.


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

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.

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".


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.

but I
have written a lot of C code that has been incorporated with other stuff
to produce programs.


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]

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.

 

[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]

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.

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]

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.

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.

But I think it goes beyond "don't mess with the implementation".

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.

 

[Yevgen Muntyan]

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.

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.

But I think it goes beyond "don't mess with the implementation".

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.

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.)

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.

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]

Yevgen Muntyan wrote, On 23/02/07 21:22:

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.

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).

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.

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.

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?"


You see, here I tightened up the definition up so that my earlier
example given on its own because "not C code".

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.

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]

CBFalconer wrote, On 23/02/07 23:07:

Flash Gordon wrote:
... snip ...

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.

 

[Yevgen Muntyan]

Yevgen Muntyan wrote, On 23/02/07 21:22:

It was indeed carefully constructed so that given an appropriate include
then you would have C code that compiles in to a C program.


Others have pointed out that there is more than one header file called
windows.h which are there for different purposes.

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.

The code as presented was not C code. If it was presented with
appropriate headers then the complete set could be C code.


No, not a complete program, just enough if it to not rely on things
which are not C.


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".
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.

I introduced it because in my opinion "is it C code?" is a far more
useful question than "is it a C program?"



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.

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).

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]

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]

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.

--
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

 

[Flash Gordon]

Yevgen Muntyan wrote, On 24/02/07 11:21:

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.

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.

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.

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.

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.

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.

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.

"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.

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.