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, 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
Feb 13 '07
111  4538 
CBFalconer wrote:
boa wrote:
>CBFalconer wrote:
>>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 ;-)
>>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-sequencenew-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 <filenamemay be entirely contained within the
compiler.
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
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>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).
Yevgen Muntyan <mu****************@tamu.eduwrote:
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
Richard Bos wrote:
Yevgen Muntyan <mu****************@tamu.eduwrote:
>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...
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
On Thu, 2007-02-22 at 10:19 +0000, Yevgen Muntyan wrote:
Richard Bos wrote:
Yevgen Muntyan <mu****************@tamu.eduwrote:
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.
--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.
Andrew Poelstra wrote:
On Thu, 2007-02-22 at 10:19 +0000, Yevgen Muntyan wrote:
>Richard Bos wrote:
Yevgen Muntyan <mu****************@tamu.eduwrote:
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/
Andrew Poelstra wrote:
On Thu, 2007-02-22 at 10:19 +0000, Yevgen Muntyan wrote:
>Richard Bos wrote:
>>Yevgen Muntyan <mu****************@tamu.eduwrote:
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
On Tue, 20 Feb 2007 02:27:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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
Yevgen Muntyan <mu****************@tamu.eduwrote:
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
Richard Bos wrote:
Yevgen Muntyan <mu****************@tamu.eduwrote:
>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 wrote:
Richard Bos wrote:
>Yevgen Muntyan <mu****************@tamu.eduwrote:
>>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.
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
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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
CBFalconer <cb********@yahoo.comwrites:
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.hand "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).
--
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.
In article <qt********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>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
Beej Jorgensen <be**@beej.uswrites:
In article <qt********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>>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.hand "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".
--
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.
Yevgen Muntyan wrote, On 23/02/07 13:33:
Richard Bos wrote:
>Yevgen Muntyan <mu****************@tamu.eduwrote:
>>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
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>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-sequencenew-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
CBFalconer wrote:
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.hmay 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
Flash Gordon wrote:
Yevgen Muntyan wrote, On 23/02/07 13:33:
>Richard Bos wrote:
>>Yevgen Muntyan <mu****************@tamu.eduwrote:
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.
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.
>>>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?)
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
Beej Jorgensen <be**@beej.uswrites:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>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.hin /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.hrefers 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.
--
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.
Keith Thompson wrote:
Beej Jorgensen <be**@beej.uswrites:
>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>>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.hin /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.hrefers 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
Yevgen Muntyan <mu****************@tamu.eduwrites:
Keith Thompson wrote:
>Beej Jorgensen <be**@beej.uswrites:
>>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
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.hin /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".
>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.hrefers 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.hin 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.
--
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 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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
>Keith Thompson wrote:
>>Beej Jorgensen <be**@beej.uswrites:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>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.hin /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.
>>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.hrefers 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.)
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.hin 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
CBFalconer wrote, On 23/02/07 23:07:
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 wrote, On 23/02/07 21:22:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 23/02/07 13:33:
>>Richard Bos wrote:
Yevgen Muntyan <mu****************@tamu.eduwrote:
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.
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).
> 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.
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 wrote:
Yevgen Muntyan wrote, On 23/02/07 21:22:
>Flash Gordon wrote:
>>Yevgen Muntyan wrote, On 23/02/07 13:33:
Richard Bos wrote:
Yevgen Muntyan <mu****************@tamu.eduwrote:
>
>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.
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.
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.
>> 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.
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.
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.has
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
On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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
On Sat, 24 Feb 2007 11:21:52 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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
Mark McIntyre wrote, On 24/02/07 12:41:
On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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
Yevgen Muntyan wrote, On 24/02/07 11:21:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 23/02/07 21:22:
>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 23/02/07 13:33:
Richard Bos wrote:
>Yevgen Muntyan <mu****************@tamu.eduwrote:
>>
>>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.
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.
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.
>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.has
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.
<sighNo, 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
Flash Gordon wrote:
Yevgen Muntyan wrote, On 24/02/07 11:21:
>Flash Gordon wrote:
>>Yevgen Muntyan wrote, On 23/02/07 21:22:
Flash Gordon wrote:
Yevgen Muntyan wrote, On 23/02/07 13:33:
>Richard Bos wrote:
>>Yevgen Muntyan <mu****************@tamu.eduwrote:
>>>
>>>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.
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.
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.
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).
>>>> 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.has
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 ;)
>>>>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.
<sighNo, 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 ;)
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)
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.hmakes them non-standard).
Yevgen
Mark McIntyre wrote:
On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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.hisn'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
In article <k27Eh.505$Tg7.397@trnddc03>,
Yevgen Muntyan <mu****************@tamu.eduwrote:
>Mark McIntyre wrote:
>On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>>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.
Yevgen Muntyan wrote, On 24/02/07 21:47:
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.has
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.
<sighNo, 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.hmakes 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
Flash Gordon wrote:
Yevgen Muntyan wrote, On 24/02/07 21:47:
>Flash Gordon wrote:
<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.hmakes 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!
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<barisn'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
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.
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
Beej wrote:
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
On Feb 25, 2:18 am, Yevgen Muntyan <muntyan.removet...@tamu.edu>
wrote:
Nobody is discussing non-conforming code. We are discussing what
*conforming* code may be called "C".
Ah. My mistake. Carry on. :)
-Beej
Yevgen Muntyan wrote, On 25/02/07 08:22:
<snip>
C++ code like std::foo(bar) or foo<barisn'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
On Sun, 25 Feb 2007 03:05:52 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>Mark McIntyre wrote:
>On Fri, 23 Feb 2007 21:22:14 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>>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
"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
On Sun, 25 Feb 2007 10:18:31 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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).
--
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 wrote:
On Sun, 25 Feb 2007 10:18:31 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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
Keith Thompson <ks***@mib.orgwrote:
Beej Jorgensen <be**@beej.uswrites:
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 rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgwrote:
>Beej Jorgensen <be**@beej.uswrites:
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 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.
--
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.
In article <45****************@news.xs4all.nl rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgwrote:
Beej Jorgensen <be**@beej.uswrites:
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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote:
In article <45****************@news.xs4all.nlrl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgwrote:
Beej Jorgensen <be**@beej.uswrites:
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" <mu****************@tamu.eduwrote...
[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
On Sun, 25 Feb 2007 23:32:05 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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.
--
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 wrote:
On Sun, 25 Feb 2007 23:32:05 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>>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.hheader, 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
On Tue, 27 Feb 2007 23:36:36 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:
>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.
--
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 This thread has been closed and replies have been disabled. Please start a new discussion. |
