Incrementing a void pointer. Legal C99?

[pete]

What's the warning?

tcc with -Xs
("strict ANSI with many extra checks") gives no complaints at all. I
don't see anything in n1124 forbidding this either. Did I miss
something?

Is (*p) equal to (p[0]) ?

(*puts) isn't equal to (puts[0]),
so the point I was trying to get at, may be irrelevant.

 

[Guest]

What's the warning?

Simply "warning: dereferencing ‘void *’ pointer".

tcc with -Xs
("strict ANSI with many extra checks") gives no complaints at all. I
don't see anything in n1124 forbidding this either. Did I miss
something?

Is (*p) equal to (p[0]) ?

(*puts) isn't equal to (puts[0]),
so the point I was trying to get at, may be irrelevant.

Not even just with function pointers, but

extern char p[];
int main(void) {
*&p; /* no error */
(&p)[0]; /* gcc: error: invalid use of array with unspecified
bounds */
return 0;
}

And tcc's error message is more verbose, but essentially the same.

 

[S.Tobias]

6.5.3.2 doesn't constrain us from dereferencing void pointers.
In fact, nothing does.

Everything is all right.

Is (*p) equal to (p[0]) ?

No.

 

[Richard Heathfield]

Harald van D?k said:

My compilers accept

int main(void) {
void *p = &p;
*p;
return 0;
}

gcc with -ansi -pedantic-errors gives only a warning,

Only a warning.

"I'm going into the cave."
"I think I'd better warn you there's a mad bear in there."
"Oh. Well, it's only a warning. Here I gAAAAAARRRRGGGHHH!"

I prefer to call them "diagnostic messages". It conveys a less casual
approach to the often ghastly problems to which your compiler is trying to
draw your attention.

tcc with -Xs
("strict ANSI with many extra checks") gives no complaints at all. I
don't see anything in n1124 forbidding this either. Did I miss
something?

Well, remember that void expressions are evaluated for their side effects.
Now try /using/ the value of the expression, and see how far you get.

 

[Guest]

Harald van D?k said:


Only a warning.

"I'm going into the cave."
"I think I'd better warn you there's a mad bear in there."
"Oh. Well, it's only a warning. Here I gAAAAAARRRRGGGHHH!"

I prefer to call them "diagnostic messages". It conveys a less casual
approach to the often ghastly problems to which your compiler is trying to
draw your attention.

The warning here means gcc does not believe it violates any
constraints, but does believe it may be an accident. It is not an
accident. I do not call it a "diagnostic message" because error
messages are that too, and I wanted to make it clear that gcc
successfully compiled the program.

Well, remember that void expressions are evaluated for their side effects.
Now try /using/ the value of the expression, and see how far you get.

Does an expression of type void even have a value? Anyway, I know there
is not a whole lot you can do with it, and there is no reason to do
this in C other than "because I can". But when it is claimed I can't,
that's reason enough for me.

 

[pete]

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= wrote:

Does an expression of type void even have a value?
No.

Anyway, I know there
is not a whole lot you can do with it, and there is no reason to do
this in C other than "because I can". But when it is claimed I can't,
that's reason enough for me.

I understand.

 

[Keith Thompson]

The warning here means gcc does not believe it violates any
constraints, but does believe it may be an accident. It is not an
accident. I do not call it a "diagnostic message" because error
messages are that too, and I wanted to make it clear that gcc
successfully compiled the program.

[...]

The standard only requires a compiler to produce a diagnostic message
when it encounters a syntax error or constraint violation. It doesn't
require a distinction between warnings and error messages, and it
doesn't require *any* program to be rejected (unless it contains a
"#error" directive).

So any compiler is allowed to respond to a constraint violation by
printing a warning message and successfully translating the file, <OT>
and gcc does so in some cases</OT>.

 

[Guest]

The warning here means gcc does not believe it violates any
constraints, but does believe it may be an accident. It is not an
accident. I do not call it a "diagnostic message" because error
messages are that too, and I wanted to make it clear that gcc
successfully compiled the program.

[...]

The standard only requires a compiler to produce a diagnostic message
when it encounters a syntax error or constraint violation. It doesn't
require a distinction between warnings and error messages, and it
doesn't require *any* program to be rejected (unless it contains a
"#error" directive).

So any compiler is allowed to respond to a constraint violation by
printing a warning message and successfully translating the file, <OT>
and gcc does so in some cases</OT>.

I am aware that in the general case, there is no such guarantee, but I
mentioned I used the -pedantic-errors option, which with GCC makes
*all* required diagnostics hard errors. Sorry for not having posted
what it meant the first time.