Cast "const char *" pointers to "char *" to avoid compiler warnings.
Corinna Vinschen
vinschen@redhat.com
Wed Oct 10 09:28:00 GMT 2018
On Oct 2 11:10, Christophe Lyon wrote:
> On Tue, 2 Oct 2018 at 00:50, Craig Howland <howland@lgsinnovations.com> wrote:
> >
> > On 10/01/2018 05:33 PM, Christophe Lyon wrote:
> > > Hi,
> > >
> > > GCC complains that some assignments loose the const-ness of several
> > > data. This small patch adds explicit (char *) casts, but I'm not
> > > familiar enough with what newlib does with these to be sure that they
> > > are not modified. Maybe the proper fix would be to declare the
> > > destinations as "const"?
> > >
> > > Christophe
> > If I understand what you're saying properly, it amounts to saying that you did
> > not verify whether the GCC warnings about discarding const are valid or not, yet
> > you are suppressing them. Is this a proper understanding? If so, it seems like
> > these proposed patches are a bad idea, as they might be hiding a real problem,
> > or changing the wrong thing. (In a very quick look at locale.c, for example,
> > locale can definitely be written to--it is definitely not const. This implies
> > that the const on new_locale is what is wrong.)
>
> I did have this "very quick look at locale.c" before writing the
> patch, and not adding
> the cast at the assignment point means removing "const" from __loadlocale()
> prototype:
> char *__loadlocale (struct __locale_t *loc, int category, const char
> *new_locale)
> which in turn has a significant impact on the callers which I hope
> people familiar
> with this area can confirm, or not.
The bug was, in fact, to define the third parameter as const, given it
gets potentially overwritten. None of the incoming values is const
anyway. I pushed a patch.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20181010/ca53c92a/attachment.sig>
More information about the Newlib
mailing list