Re: [Libguestfs] [libnbd PATCH] maint: pick consistent spacing style for casts
On Wed, May 24, 2023 at 02:09:30PM +0100, Richard W.M. Jones wrote:
On Wed, May 24, 2023 at 07:39:20AM +0200, Laszlo Ersek wrote:
> Going through the changes individually, it seems like we could eliminate
> a handful of the casts altogether; for examle (char *)"string literal"
> ones.
It'd be interesting to remove then and compile with
'./configure --enable-gcc-warnings' to see if that creates new
warnings.
> (The C standard effectively says that a (non-wide) string literal
> has type "static char[n]", not "static const char[n]".) But
that
> would be a different patch, plus I can imagine we have those casts
> in the first place because gcc complained or whatever. :)
It's a bit surprising. Surely any string literal is placed in the
text section so definitely not writable?
C17 6.4.5 Paragraphs 6 and 7
"... The multibyte character sequence is then used to initialize an
array of static storage duration and length just sufficient to contain
the sequence. For character string literals, the array elements have
type char, ..."
"It is unspecified whether these arrays are distinct provided their
elements have the appropriate values. If the program attempts to
modify such an array, the behavior is undefined."
Yeah, it's weird. In C, a string literal has the effective type 'char
*' except that you cannot safely modify its contents; it's due to
historical back-compat to pre-standard compilers that lacked 'const
char *'. C++ on the other hand treats string literals as const char
*; code that intends to be compiled in either language must explicitly
cast away the const.
I've checked that the compiler does not complain if we remove casts
that only serve to explicitly document that we are removing const when
passing a string literal to a place that wants a 'char *' but will
otherwise not modify the contents.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org