[MPlayer-cvslog] r23255 - trunk/libmenu/menu.c

[Uoti Urpala]

On Mon, 2007-05-07 at 23:10 +0200, Reimar Döffinger wrote:
> > >> +      c = utf8_get_char((const char**)txt);

> > utf8_get_char requires a const, it just kills a warning.
> 
> And why on hell is that stupid compiler warning about it? Unless someone
> comes up with a good reason for the warning I'd be strongly in favour of
> ignoring the warning.

The C standard requires that conversions between certain pointer types
work, such as "int *"->"void *" and back or "char *"->"const char *",
but it doesn't require that the conversion keep the byte representation
the same. In principle such casts could create a significantly different
object, like conversion from int to double. An intentionally annoying
compiler could for example add 100 to all const pointers (and of course
substract 100 from all dereferences and add/substract 100 when there's
an explicit conversion to/from const). Code such as the above would then
fail, because the non-const->const change is about the pointed-to
objects (which the cast can't modify) rather than the direct target of
the cast. So from the view of the C standard this code is comparable to
casting (int *) to (double *); you can convert int to double without
losing information, but you can't convert and then dereference pointers
like that without converting each pointed-to element individually.

Of course practical platforms do not show such behavior. Generally
conversions between pointer types do not affect the representation of
the pointer, and pointer type mismatches do not matter as long as types
used for dereferencing are correct.