Re: Automatically generate variables

santosh wrote:
Yevgen Muntyan wrote:
santosh wrote:
Yevgen Muntyan wrote:
Mark McIntyre wrote:
jacob navia wrote:
Mark McIntyre wrote:

<snip>

#include <stdio.h>
#include <windows.h>
Beep beep. This isn't C.

<snip>

Nonsense. It is C. It's not strictly conforming, it won't work
almost anywhere, it's rather useless, it's off-topic here, all this
was in details explained in another reply to JN post. But it is C,
where "C" means "C language as defined by the ISO standard".
But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard.
This is true, but we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
is what I call nonsense, simply because it's too restrictive - if
one accepts such definition of a "C program", then all those C
programmers out there are writing programs in some fancy language
which is not C, and all those C programs out there are not C
programs. Then, I think the standard exists to make people able
to write C programs using extensions. And it uses term "strictly
conforming" exactly to distinguish programs which are completely
described and programs which use extensions but are still C programs,
but to not restrict itself only to those strictly conforming
programs. The syntax and semantics of "a C program" have very big
value, what would be the point of having the standard which simply
stops working as soon as non-standard header is used?

<rest snipped>

I can see your reasoning.

The imaginary boundary which divides a peice of code from being
reasonably called as C from being in a C-like language is undefined
and blurred. The standard fully defines conforming C programs.

No it doesn't, it fully defines strictly conforming programs,
the ones which in particular do not contain code like

#include "foo.h"

"Just" conforming is no good, C++ programs seem to be conforming
because gcc accepts them, and gcc is a conforming implementation
(GNU compiler collection, that is, not the binary called 'gcc').

In
addition it allows implementation specific decisions for various
aspects and extensions as well. Certainly the code posted by jacob
navia qualifies as C code. The issue is what we exactly mean by term C
code. If we mean "the language as defined by the C standard", (which
is what you wrote earlier), then does his code snippet qualify as C
code? I think so.

Yes, I do think so too.

But what about more fundamental extensions like the && gcc extension
discussed in another thread or the various operator overloading
features implemented by the lcc-win32 compiler? Can code that use such
"radical" extensions still be called as C? I don't think so.

I agree here too.

What
makes one extension reasonable and another not, from the POV of being
compatible with C?

And I don't know the answer for this. And as I said, I don't think
one can provide sensible answer which would not involve what one
feels as opposed to what exactly is said in some definition.

Unless we take the strict approach of adhering to what the standard
specifies and allows, we seem to get into a lot of "gray areas" about
what is, and is not, C. It seems to ultimately come down to personal
opinion,

True. But it's not bad. It seems to me people generally agree on
what's C and what's not C (unless it's an argument in comp.lang.c).
And that's what really matters.

something I'm not happy about.

Sure, it would be easier if the standard said "this is C, and the
rest isn't C and I don't care about that", but then the standard
would be useless. So we have what we have. I believe it's called
"trade off" in English.

Yevgen
.

Relevant Pages

  • Re: c compiler?
    ... Extensions are explicitly permitted by the standard: ... A conforming implementation may have extensions (including ... newsgroup*, particularly without making it sufficiently clear that any ...
    (comp.lang.c)
  • Re: Is ISO Pascal compatible with J&W (original) Pascal ?
    ... So if someone writes a program that can be happily processed by a particular conforming processor, that PROGRAM does not neccessarily conform to the standard and is therefore not neccessarily portable. ... IMHO a standard should not explicitly allow undefined extensions: I think that is where a lot of people are likely to become critical of the standard. ... I don't think that that example illustates a lack of portability. ...
    (comp.lang.pascal.misc)
  • Re: Is ISO Pascal compatible with J&W (original) Pascal ?
    ... The Original Pascal allows for predefined Procedures and Functions but the ISO standard goes further and allows for redefinitions of chapter 6: hence your IPPascal may accept the underscore in identifiers. ... The interesting point is that the standard is very forgiving in what the PROCESSOR is allowed to accept but at the same time very strict on what is allowed in a conforming PROGRAM. ... IMHO a standard should not explicitly allow undefined extensions: I think that is where a lot of people are likely to become critical of the standard. ...
    (comp.lang.pascal.misc)
  • Re: standards documents off-topic in comp.lang.c
    ... C89/C90 is the only standard widely used. ... Conforming C99 ... >There are plenty of libraries that implement extensions (POSIX is one ... Which, basically, means that, when invoked in standard conforming mode, ...
    (comp.lang.c)
  • Re: Making C better (by borrowing from C++)
    ... MS header files, or whatever, it's undefined by the standard how those ... >> possible to compile so that the method is what the compiler produces by ... all the extensions of lcc-win32 are exactly like ... is not compliant, it doesn't matter ...
    (comp.lang.c)