svn commit: r286601 - head/usr.bin/patch

[Bruce Evans]

On Mon, 10 Aug 2015, Xin Li wrote:

> On 8/10/15 22:51, Ed Schouten wrote:
>> 2015-08-11 1:20 GMT+02:00 Xin Li <delphij at delphij.net>:
>>> Do you have a better solution for this?  No, this is not ideal
>>> but I didn't find a better alternative (or maybe I have missed
>>> something obvious?)
>>>
>>> I think with the current POSIX definition of the interface, we
>>> have only two options: either strdup() or cast away const (I'd
>>> rather hide this kind of uglyness in the library), no?
>>
>> Casting const away should be all right in this case.

It is the Standard way.

> Committed as r286617, please let me know if you want other
> changes, etc.
>
> Perhaps we should convert the tree over time to use __DECONST instead
> then?

Gak!.  I use rmrf on code with __DECONST in it.

The misimplementation of __DECONST only "works" because -Wcast-qual is
too broken to detect removal of qualifiers by casting a pointer to an
integer.  Casting a pointer to an integer is much less safe than
casting away only a qualifer for a pointer, but both are Standard,
so they work unless the compiler is directed to be nonstandard using
-Wcast-qual -Werror.

Compilers should know about the language defects that make it impossible
to declare functions like execv() with the correct number of const's
and turn off -Wcast-qual warnings for these functions.

strchr() is another function that needs special.  It can take a pointer
const char and return a related pointer with the const qualifier removed
(subtract an offset to get the original pointer with its const qualifier
removed).  The warning about this from -Wcast-qual is not yet killed
using __DECONST() because libc is still compiled with a low WARNS.
The implementation uses a cast in the Standard way.  Only the
implementation would be affected by -Wcast-qual.  But a flag like
-Wcast-qual should direct the compiler to warn about removal of casts
by abusing strchr() too.

Bruce