Best way of clearing a compiler warning?

[Michael Wojcik]

gcc is still a C compiler with -Wwrite-strings, since the resulting code
is semantically equivalent to code where string literals are not
const, including undefined behavior for modifying literals.

And if that were the definition of a conforming implementation,
you'd be right. But it is not.

In a conforming implementation, character string literals have type
"array of char". Period. C99 6.4.5 does not allow any waffling
about semantic equivalence.

 

[Keith Thompson]

And if that were the definition of a conforming implementation,
you'd be right. But it is not.

In a conforming implementation, character string literals have type
"array of char". Period. C99 6.4.5 does not allow any waffling
about semantic equivalence.

At execution time, nothing really has a type; it's all zeros and ones.
An implementation is conforming if it behaves in a conforming manner.
If its documentation says that string literals are const, that doesn't
affect conformance, since the type of string literals isn't one of the
things an implementation is required to document.

As far as I know, gcc's treatment of string literals as const doesn't
affect the behavior of any strictly conforming program, cause any
strictly conforming program to fail to compile, or cause any required
diagnostic to fail to appear. (I'd be interested in seeing a
counterexample.) It does cause some non-required diagnostics to
appear, and some of those diagnostics are factually incorrect, but
that's not a conformance issue.

Of course, "-Wwrite-strings -Werror" does make gcc non-conforming;
"-Werror" causes warnings to be treated as errors.

 

[Skarmander]

And if that were the definition of a conforming implementation,
you'd be right. But it is not.

In a conforming implementation, character string literals have type
"array of char". Period. C99 6.4.5 does not allow any waffling
about semantic equivalence.

So if gcc acts as a conforming implementation despite this option, gives
warnings when string literals are assigned to non-const pointers, and if
it had not described this effect in its documentation as assigning a
const type to literals, would that still be in violation?

This is getting to the point of a "tree falling in a forest with nobody
around to hear it" discussion, I admit. On one level, you are of course
right: the standard says to do A and gcc explicitly claims to do B,
which excludes A, hence it doesn't conform. But my (educated guess) is
that the difference can't be observed except through seeing additional
diagnostics, which the standard explicitly allows regardless of nature.

Whether you then feel justified calling gcc "(not) a C compiler" is a
question of how you line up your definitions, and how you define
conformance to an abstraction. It's not really a productive avenue of
discussion.

S.

 

[Jordan Abel]

So if gcc acts as a conforming implementation despite this option, gives
warnings when string literals are assigned to non-const pointers, and if
it had not described this effect in its documentation as assigning a
const type to literals, would that still be in violation?

This is getting to the point of a "tree falling in a forest with nobody
around to hear it" discussion, I admit. On one level, you are of course
right: the standard says to do A and gcc explicitly claims to do B,
which excludes A, hence it doesn't conform. But my (educated guess) is
that the difference can't be observed except through seeing additional
diagnostics, which the standard explicitly allows regardless of nature.

I suppose the "as if" rule would have to apply here. It's acting "as if"
it is a conforming implementation with some spurious diagnostics. Now,
if the standard required that programs which attempt to assign to const
or otherwise violate const should fail to compile (AFAIK the standard is
not in the business of requiring things to fail to compile, only that
diagnostics must be printed), then gcc would be stuck between a rock and
a hard place, but still could get out of it by adding a "weak" const
which applies to only string literals - in which case, if a const falls
in a forest and no-one's around to read the diagnostic, did it really
happen?

 

[pete]

Keith Thompson wrote:

As far as I know, gcc's treatment of string literals as const doesn't
affect the behavior of any strictly conforming program, cause any
strictly conforming program to fail to compile, or cause any required
diagnostic to fail to appear.

Is there anything you can do with a string literal
in a C program, that you couldn't do if string
literals were const qualified by default?

I don't think so.

 

[Daniel Rudy]

At about the time of 11/6/2005 8:54 PM, Keith Thompson stated the following:

[...]

Here's my command line:

gcc -W -Wall -Wshadow -Wpointer-arith -Wcast-align -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Wwrite-strings -Wfloat-equal

^^^^^^^^^^^^^^^
There you go. If you remove that, your original code should
compile free of that particular warning.

-Winline -Wtrigraphs -pedantic -ansi -std=c89 -ggdb3 -I.. -lm -lmd -lc
-lcrypto -o digest.test digest.test.c digest.c ../sha2.c ../error.c
../syslog.c

Yes, but it's a good warning.

Here's an inexact summary of the code in question:

void error(char *errmsg, int code);
...
error("This is an error message", errno);

Given this, the compiler can't tell whether error() modifies the
string passed to it. If it could analyze the actual implementation of
the error() function, it could safely refrain from warning about the
use of a string literal.

The best way to handle this is for the error() function to promise not
to modify the string that its argument points to; the compiler than
then warn about calls that might potentially violate that promise.

FWIW, the reason why I specify the warnings that I do is to force me
into writing clean, conforming, and correct code that will compile and
run on the widest number of systems out there with any problems. Right
now, my code will work on *BSD systems and possibly Linux as well, but
this is a platform issue, not a C issue.

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Richard Bos]

Is there anything you can do with a string literal
in a C program, that you couldn't do if string
literals were const qualified by default?

Assign them to char *s without sprinkling your code with numerous
superfluous (and therefore evil) casts.

Richard

 

[pete]

Assign them to char *s without sprinkling your code with numerous
superfluous (and therefore evil) casts.

Ah, yes, the subject of this thread!

 

[Michael Wojcik]

On the other hand, what I wrote is also not the definition of a
conforming implementation, which only has to accept any strictly-
conforming program (relaxed for freestanding implementations), not
alter the behavior of any strictly conforming program, and document
implementation-specified behavior.

For some reason when I posted the above I was thinking that
explicitly contradicting the standard rendered an implementation
non-conforming, but - unintuitive though it might be - it does not.

Someone noted that gcc with -Wwrite-strings -Werror is nonconforming,
because it refuses to accept the following strictly-conforming
program:

int main(void) {char *a = "a"; return 0;}

But just changing the type of string literals alone does not, AFAICT,
make it nonconforming.

So if gcc acts as a conforming implementation despite this option, gives
warnings when string literals are assigned to non-const pointers, and if
it had not described this effect in its documentation as assigning a
const type to literals, would that still be in violation?

No; I was wrong (though I don't believe the standard defines "in
violation" - I'll take that as a synonym for "nonconforming"). If
it documents -Wwrite-strings as changing the type of string literals,
it contradicts the standard, but this does not make it nonconforming.
If it omits that (to my mind ill-considered) remark in the documenta-
tion, it's not even contradicting the standard.

 

[Michael Wojcik]

At execution time, nothing really has a type; it's all zeros and ones.

True, but I don't see how that's relevant. The standard doesn't care
about execution, except insofar as a conforming implementation is
required to not alter the behavior of any strictly-conforming program.
On the other hand, the standard *is* quite concerned about the types
of objects.

However, it's all pretty much moot, as I realized that, of course,
explicitly contradicting the standard does not in and of itself render
an implementation nonconforming. See my reply to Skarmander.