Re: (part 8) Dick Heathfield's book errors

[Malcolm McLean]

"Nomen Nescio" <nobody@dizum.c omwrote in message

>
#define EOL_LENGTH 12
>
["Macros that begin with E and a digit or E and an uppercase
letter..." are reserved.]
>
It's fun when the tables of senseless, illogical nitpicking
get turned on the CLC Clique, isn't it?
>

It is not exactly senseless. Code is either compliant or not.

The problem is that the rules have the side-effect of banning identifiers
like "tomorrow", "strength", or EOL_LENGTH, which is ENTIRELY too strict.


--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[Ben Bacarisse]

Re: (part 8) Dick Heathfield's book errors

"Malcolm McLean" <regniztar@btin ternet.comwrite s:

"Nomen Nescio" <nobody@dizum.c omwrote in message

>>
>#define EOL_LENGTH 12
>>
>["Macros that begin with E and a digit or E and an uppercase
>letter..." are reserved.]
>>
>It's fun when the tables of senseless, illogical nitpicking
>get turned on the CLC Clique, isn't it?
>>

It is not exactly senseless. Code is either compliant or not.
>
The problem is that the rules have the side-effect of banning
identifiers like "tomorrow", "strength", or EOL_LENGTH, which is
ENTIRELY too strict.

I am not sure that debating with this person will be fruitful but I am
happy to discuss the matter with you.

As far I know, the OP is wrong about the bug report, but they gave too
little information to be sure. Also, I don't think you have given
enough information to help learners since the restriction is not on
the identifier alone, but on its linkage as well.

So, in attempt to be helpful I will state what I think is case and I
will get a flurry of corrections if I am wrong.

EOL_LENGTH is a valid macro name unless errno.h is included. It might
be better to avoid such names, but that is not the same as saying some
code defining this name has a bug.

tomorrow and strength are valid identifiers provided that they don't
have external linkage. You may have to #undef the name if you include
one or other of the relevant headers *and* your implementation has
defined the name as both a function and as a macro, but such cases
will be (a) documented extensions that a good compiler will let you
turn off and (b) won't get though the compiler without some sort of
diagnostic. Saying the rules indirectly ban them is going a bit too
far, in my opinion.

It would have been better if all standard reserved names were easy to
spot, but that horse had bolted long before ANSI got hold of C.

--
Ben.

[Barry Schwarz]

Re: (part 8) Dick Heathfield's book errors

On Sun, 2 Nov 2008 16:29:41 -0000, "Malcolm McLean"
<regniztar@btin ternet.comwrote :

>
>"Nomen Nescio" <nobody@dizum.c omwrote in message

>>
>#define EOL_LENGTH 12
>>
>["Macros that begin with E and a digit or E and an uppercase
>letter..." are reserved.]
>>
>It's fun when the tables of senseless, illogical nitpicking
>get turned on the CLC Clique, isn't it?
>>

>It is not exactly senseless. Code is either compliant or not.
>
>The problem is that the rules have the side-effect of banning identifiers
>like "tomorrow", "strength", or EOL_LENGTH, which is ENTIRELY too strict.

Rules only exist to be restrictive. Every rule prohibits something
someone wants to do.

"tomorrow" is only reserved as a function name. Ditto for "strength".

--
Remove del for email

[CBFalconer]

Re: (part 8) Dick Heathfield's book errors

Malcolm McLean wrote:

"Nomen Nescio" <nobody@dizum.c omwrote in message

>>
>#define EOL_LENGTH 12
>>
>["Macros that begin with E and a digit or E and an uppercase
>letter..." are reserved.]
>>
>It's fun when the tables of senseless, illogical nitpicking
>get turned on the CLC Clique, isn't it?

>
It is not exactly senseless. Code is either compliant or not.
>
The problem is that the rules have the side-effect of banning
identifiers like "tomorrow", "strength", or EOL_LENGTH, which
is ENTIRELY too strict.

Bear in mind that Nomen Nescio is a troll.

However, the rule allows for the fact that, in the days preceding
the issuance of C89, many compiler systems defined many common
values. These required protection, and the names could not be
changed without invalidating much existing code. Therefore the
various rules.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Peter Nilsson]

Re: (part 8) Dick Heathfield's book errors

Barry Schwarz <schwa...@dqel. comwrote:

<regniz...@btin ternet.comwrote :

The problem is that the rules have the side-effect
of banning identifiers like "tomorrow", "strength",
or EOL_LENGTH, which is ENTIRELY too strict.

And what about for, while, if, etc... I really want to
use those sometimes! :-)

Rules only exist to be restrictive.
> Every rule prohibits something someone wants to do.

Up with this I will not put. ;)

"tomorrow" is only reserved as a function name.
 Ditto for "strength".

That's too restrictive! They are reserved for external
linkage identifiers, which doesn't preclude internal
linkage. Although, if associated headers are included,
they are reserved as file scope identifiers, which is
not limited to functions; and use as macros, though
the macros can be subject to #undef.

--
Peter