Re: Another spinoza challenge

Dennis (Icarus) wrote:
"Flash Gordon" <smap@xxxxxxxxxxxxxxxxx> wrote in message news:6b0bm6xh9s.ln2@xxxxxxxxxxxxxxxxxxxxxxxxxx
Dennis (Icarus) wrote:
"Flash Gordon" <smap@xxxxxxxxxxxxxxxxx> wrote in message news:91s9m6x8mq.ln2@xxxxxxxxxxxxxxxxxxxxxxxxxx
Dennis (Icarus) wrote:

<snip>

All it asked was what's a valid variable name - an implementation-defined variable in a header would be valid.
It'd be unusual, but valid.

An implementation could define behaviour for this post making it valid C, so by your definition EVERY possible file is valid C since some implementation could define behaviour for it.

That's not what I said, and not sure where you're deriving that.

The point I was driving at is that a specific implementation allowing something beyond the C standard does not make a it valid beyond that implementation, so a general statement it is valid is not appropriate.

It's a variable, and the name is syntactically valid.

Yes, but that is syntactic validity rather than validity in general.

A translation unit containing only the line...
int main;
is syntactically valid. However, try writing a program for a hosted implementation where that is one of the translation units.

In any case, if a C compiler specifies behaviour for some specific construct which the C standard doesn't, it is valid for the specific compiler, not valid in general, making it perfectly reasonable to say it is not valid (or to not include it in the list of valid identifiers).

The question asked what is a valid variable name.

It is, as an implementation can have
extern int _MAX_POWER;
in a header.

Do you agree with that?

An implementaion can do
#define _MAX_POWER 32
In which case you cannot use _MAX_POWER as a variable on that implementation. Do you agree with that? If so, that shows that apart

Of course.

OK, so on such an implementation, is _MAX_POWER valid as a variable name? Just to avoid any get-out you might think of, the implementation behaves as if that #define has been provided to all translation units (which it is allowed to) and aborts compilation on any attempt to either undefine or redefine it (which it is also allowed to).

from specific implementations which document _MAX_POWER as being allowable for a variable, it is not valid, because it might lead you to having (after macro expansion
int 32;
So in general it is not valid, and that is important for a test which is not about a specific implementation.

Remember, the question simply asked about valid identifiers.
It should be pretty clear that it is, reserved for the implementation because of the leading _, but it is a valid identifier.

Yes, which make it not unambiguously valid, since it might not be valid (as in an attempt to use it as an identify might cause compilation to abort with an error).

Can you see now why a reasonable interpretation of the word "valid" would lead to consider _MAX_POWER as not being valid?

Onky if you read in more that what is being asked.

No, I think it is a perfectly reasonable interpretation of the word valid in the context of a test on C. To the point where on a non-multiple choice test where the question was...
Is _MAX_VALUE a valid identifier?
I would mark as "fail" an answer of "yes", even if the test was given to a beginner. An answer of "no" would not get full marks either, but would get some!

I've never said it is the ONLY possible interpretation, only that it is a reasonable one.

<snip>

I still say my interpretation is reasonable.
--
Flash Gordon
.

Relevant Pages

  • Re: A question about ifndef
    ... >> Ben Pfaff wrote: ... >>>It's not just for compilation performance. ... >>>probably omit them in my header files, ... > struct fred {int i;}; ...
    (comp.lang.c)
  • Re: matrices
    ... There is no standard header. ... Doing it indirectly does NOT help improve compilation speed ... These two statements above are very strange. ... addition operator shouldn't be telling everybody it's doing its job. ...
    (comp.lang.cpp)
  • Re: What is LISP good for, that is harder in other languages?
    ... |> A much bigger problem is that you need to construct ... | compilation unit requires the compiler to start from a completely blank ... This also used to be a problem with TOPS-10 Monitor builds. ... small sources files each with *dozens* of includes of header ...
    (comp.lang.lisp)
  • Re: Another spinoza challenge
    ... "Flash Gordon" wrote in message ... variable in a header would be valid. ... An implementation could define behaviour for this post making it valid C, so by your definition EVERY possible file is valid C since some implementation could define behaviour for it. ... construct which the C standard doesn't, it is valid for the specific compiler, not valid in general, making it perfectly reasonable to say it is not valid (or to not include it in the list of valid identifiers). ...
    (comp.lang.c)
  • Re: Best Practices: #include
    ... It does not require that the header file be included in every file; ... If the header file has been included once, in a given compilation, any subsequent ... the file not be included by #pragma once until it has been included one time, ... allows the header to be read where it's contents are unknown" is also content-free. ...
    (microsoft.public.vc.mfc)