Subject: Re: toolchain/22118: make won't compile with -Wcast-qual -Wstrict-prototypes and more
To: NetBSD Toolchain Technical Discussion List <tech-toolchain@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-toolchain
Date: 07/17/2003 16:16:42
>>> I don't know which references you've relied upon, but read-only
>>> storage really must be const-qualified in order to make
>>> -Wconst-qual warnings be of any use whatsoever.
[s/-Wconst/-Wcast/ of course]
>> (a) Even if that were true, it's a gccism with little bearing on C.
> No, it's not a GCCism.

No?  How many non-gcc compilers have -Wcast-qual?  That whole sentence
is of the form "<foo> in order to make -Wcast-qual warnings <bar>",
which is meaningless for environments lacking -Wcast-qual.

> In ISO Standard C all string constants may be stored in read-only
> storage and identical string constants may be stored at the same
> address.

Yes.  This has nothing to do with whether their type invovles "const".

> Finally note that it doesn't really matter what any standard or
> compiler says or does about string constants used in expressions.

You seemed to think it did, babbling about what Standard C did or did
not specify.

> GCC [...] (currently) uses "const char *" as the type for string
> constants

(a) Not by default.  Only when -Wwrite-strings is used.

(b) No, const char [N] for a value of N which depends on the number of
    characters in the string.  (This is a somewhat pedantic point,
    since it does turn into const char * in rvalue contexts.)

> in initializers

In initializers of array-of-char, double-quoted text that looks like a
string literal _does not have_ a type, since it's not a string literal
in the usual sense, just a textual abbreviation for an initializer list
containing chars.  In initializer expressions (including trivial
expressions initializing pointer variables), a string literal is
occurring in an rvalue context, same as it is in any expression; that
expression's being in an initializer is irrelevant.

> so _portable_ code must assume this is true even if the ISO C
> Standard says it is not.

So now that the Standard turns out to be against your position, it's
irrelevant?  How, um...convenient.  Sorry, pointing at The Standard as
grounds for your argument rather vitiates any attempt to ignore it when
it turns out you were wrong about what it says.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B