Re: Automatically generate variables

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

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. What
makes one extension reasonable and another not, from the POV of being
compatible with C?

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, something I'm not happy about.

.

Relevant Pages

  • Re: help to understand
    ... > provided by UNIX. ... > But if you compile your code as a strictly conforming UNIX application, ... The standard also has the concept of a "Conforming POSIX Application ... It says a similar thing for XSI applications using extensions. ...
    (comp.unix.programmer)
  • 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)
  • Re: idea: on the issue of C and language extensions
    ... features; this route would be based mostly on something like a mailing ... implementations, yet far lighter weight and informal than forcing ... extensions they have done already... ... When parts of the Standard released by such a major organisation like ...
    (comp.std.c)
  • Re: what parallel C language does MIPS Pro C Compiler support?
    ... > Besides - C is still C even when there are extensions. ... learning how ... to do the core standard C sandbox "correctly" is 95% of the ... or so capable that no platform-specific library API will ...
    (comp.lang.c)
  • Re: Making C better (by borrowing from C++)
    ... > possible to compile so that the method is what the compiler produces by ... I would have to rewrite the 15 000 APIs that Windows ... all the extensions of lcc-win32 are exactly like ... >>BY DEFINITION in the standard itself. ...
    (comp.lang.c)