diffrence?

[Richard]

Why? Windows programmers should certainly know how Windows works, as
should anyone who needs to a write a program which might need to be
ported to Windows, and might need to be modified in order to perform
the port (my own code should be compilable under Windows, but it
should also require no modification to achieve that result - however,
I have no access to any machine where I could test whether or not this
is the case).

Why in the world should anyone else treat it as anything other than "a
big mystery"? I'm not saying that happening to have such knowledge is
harmful; but your use of "should" implies that people should go out
of their way to acquire this information. Why should they waste their
time in that fashion?

Because if you do not you might miss some subtle issue with Windows
which leads to less reliable code. Thats why.

 

[James Kuyper]

....

Because if you do not you might miss some subtle issue with Windows
which leads to less reliable code. Thats why.

How could it lead to less reliable code if the code doesn't run under
Windows? Even if it does run under Windows, are you suggesting that
strictly conforming code requires __cdecl in order to work reliably
under Windows? Any compiler that produces an unreliable executable when
given strictly conforming code does not conform to the C standard.

 

[Richard Tobin]

How could it lead to less reliable code if the code doesn't run under
Windows? Even if it does run under Windows, are you suggesting that
strictly conforming code requires __cdecl in order to work reliably
under Windows? Any compiler that produces an unreliable executable when
given strictly conforming code does not conform to the C standard.

From what I was told by those who compiled my code on Windows, it's
not that the compiler can't compile strictly conforming code, but that
in order to interoperate with certain other programs and libraries on
the system you have to use various magic keywords.

-- Richard

 

[James Kuyper]

From what I was told by those who compiled my code on Windows, it's
not that the compiler can't compile strictly conforming code, but that
in order to interoperate with certain other programs and libraries on
the system you have to use various magic keywords.

Sure - but that doesn't mean that it's needed for programs running under
Windows; it only means that it's needed to make use of those programs
and libraries.

 

[Keith Thompson]

Keith Thompson said:


Only when being compiled on an implementation that supports those
extensions with that syntax and those semantics. On implementations that
don't, it's just an error.

I'd call it non-portable C (and therefore still C) that isn't
supported by the current implementation.

If I have a file named "hello.c" with the following contents:

#include <stdio.h>
int main(void) { puts("hello, world"); return 0; }

it remains C whether I happen to have a C implementation available or
not.

It's the same problem as void main. C99 tried to "fix" void main (and
double main, and struct tm **main) by, in a sense, codifying different
syntaxes for main - but did so in a way that is inherently meaningless.
Yes, extensions are part of C in the sense that C compilers can accept
(and even define) them, but they are not part of C in the sense that
compilers can reject them.

Compilers can reject program that declare objects bigger than 65535
bytes. That doesn't make a program that declares such an object
non-C; it merely makes it non-portable C.

Since C is specifically designed to allow for writing non-portable
code (though it's certainly also possible to write portable C code),
it seems silly to say that any C code that's not portable is not C.

Consider this:

now is the time for all good men to come to the aid of their party

According to you, there are good grounds for considering this to be C.
After all, any implementation is allowed to grant it meaning as an
extension. And the token sequence even appears in K&R2!

I doubt that any existing C implementation provides an extension which
makes the above anything other than a syntax error (unless, of course,
it appears in a string literal, in a comment, or perhaps in a few
other contexts I won't bother to think about). If I'm correct, then
it doesn't qualify as a "conforming program" in the sense defined in
C99 4p7. (You could probably write a conforming implementation that
accepts it in a few minutes, as a wrapper around an existing
conforming implementation.)

What about this?

WRITE OUTPUT TAPE 6, 601, IA, IB, IC, AREA

(I am given to understand from clc discussions over the last few years that
there is at least one conforming implementation that accepts Fortran
programs.)

gcc certainly accepts Fortran programs, if it's been configured to do
so (you can choose during installation which languages to support).
But a given compiler with different sets of command-line options can
be two different implementations. gcc normally determines the
language to compile by looking at the suffix of the source file name;
".c" is C, ".cpp" or ".C" is C++, ".f" is Fortran, ".adb" or ".ads" is
Ada, etc. I would argue that the file suffix is effectively a
command-line option, so "gcc -c hello.c" and "gcc -c hello.f" invoke
two different implementations.

If I could take a file "hello.c" containing

#include <stdio.h>
int main(void) { puts("hello, world"); return 0; }

and have an implementation accept it, then change the contents
of "hello.c" to

WRITE OUTPUT TAPE 6, 601, IA, IB, IC, AREA

and still have the implementation accept it *with the same options*,
then I'd be willing to say that a C implementation accepts Fortran
code.

Whenever we try to classify anything as "is X" or "is not X", there is a
risk that the line will be blurred. About the best we can do is to realise
that there are some things that definitely are X, some things that are
definitely not X, and a fuzzy boundary in between that is best avoided
when clarity is more important than a futile attempt to achieve
classificatory perfection.

I finally went back and re-read your previous statement, which I think
I misinterpreted. You said that if the use of __cdecl is *required*,
then what we're doing isn't C programming. I agree; no conforming C
implementation can require the use of __cdecl.

On the other hand, a conforming C implementation can *allow* the use
of __cdecl, and can require it if you want to achieve some goal that
can't be achieved in portable standard C.

The discussion then moved to the question of whether C with extensions
is still C. That's within the fuzzy boundary you mentioned -- but I
still say that a program that uses __cdecl, though it certainly isn't
portable C, may nevertheless be (non-portable) C.

I'll also say that not all things that are C are appropriate for
discussion in this newsgroup.