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  4698 
Keith Thompson wrote:
Beej Jorgensen <be**@beej.uswr ites:
>In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:
>>>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.eduwr ites:
Keith Thompson wrote:
>Beej Jorgensen <be**@beej.uswr ites:
>>In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:
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.
Interestin g. 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_Keit h) 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.eduwr ites:
>Keith Thompson wrote:
>>Beej Jorgensen <be**@beej.uswr ites:
In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:
>7.1.2 paragraph 3:
> If a file with the same name as one of the above < and >
>delimite d
> 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.eduwr ote:
Richard Bos wrote:
>You're the one using non-Standard extensions and claiming they're
>perfectl y good C. I suggest that _you_ come up with your
>definiti on 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
>conformi ng 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.eduwr ote:
>
>Richard Bos wrote:
>>You're the one using non-Standard extensions and claiming they're
>>perfect ly good C. I suggest that _you_ come up with your
>>definitio n of
>>what is and is not a C program. Be careful, now: some definitions
>>are
>>trickie r than they first seem. For example, simply replying "any
>>conformin g 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.eduwr ote:
>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.eduwr ote:
>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.eduwr ote:
>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 This thread has been closed and replies have been disabled. Please start a new discussion. |
