[vlc-devel] [PATCH] fix "initialization from incompatible pointer type" warnings at libvlc-common.c:1406 and libvlc-common.c:1812

[Rafaël Carré]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Thu, 17 Apr 2008 11:21:29 -0400,
"Michael [Plouj] Ploujnikov" <ploujj at gmail.com> a écrit :

> On Thu, Apr 17, 2008 at 6:05 AM, Rémi Denis-Courmont
> <rem at videolan.org> wrote:
> > Le jeudi 17 avril 2008, Pierre d'Herbemont a écrit :
> >
> > > On Apr 17, 2008, at 7:40 AM, Rafaël Carré wrote:
> >  > > -----BEGIN PGP SIGNED MESSAGE-----
> >  > > Hash: SHA1
> >  > >
> >  > > Le Wed, 16 Apr 2008 23:19:02 -0400,
> >  > >
> >  > > Michael Ploujnikov <ploujj at gmail.com> a écrit :
> >  > >> Apparently, C can't automatically make such a pointer
> >  > >> conversion.
> >  > >
> >  > > If the compiler says we are making strange things, we should
> >  > > let the warning here to be aware there's something wrong.
> 
> First of all, I interpret this code:
> 
> const char *const *pp_shortcut = p_parser->pp_shortcuts;
> 
> as creating a pointer to access some data while guaranteeing that the
> data will only be read and not changed. This is done by using a
> "pointer to const pointer to const char" (const char *const
> *pp_shortcut). To me this sounds like a good approach to preventing
> accidental changes to data where write access is not needed.

yes

> As far as I can see, the compiler is complaining because the C
> standard [1] simply does not specify an automatic conversion from
> non-const to const qualified values. I did not find any mention of
> such conversions in that document, and some experienced C user assured
> me that I won't find it there. On the other hand, the C++ standard[2],
> allows for such a conversion. Based on my understanding of the
> terminology-filled language used in the document, such conversions are
> dealt with somewhere in section 4.4.

Section 4.4 refers to "cv-qualifiers", their order is listed in table 8
Section 3.10 (was this document written by robots ? ><)

> I would like to use this fact as
> an argument even though I understand that C and C++ are radically
> different languages.

The date of this pdf says 2008, maybe more experience went into writing
it than into last C standard ;)

> With all that in mind, I _feel_ that that using the casts as in my
> patch is a good way of keeping code relatively safe and removing
> distracting compiler warnings [3].

Why not ?

What I see is that p_parser->pp_shortcuts can not point to const data
since it's modified in various places (for example in CacheLoad() ).

If we are sure the warning doesn't learn anything, then it's ok to
suppress it to focus on real problems.

I will anyway ask pdherbemont & courmisch since they
supported me in my position ;)

> On the other hand, maybe the local
> variable pp_shortcut should just be a "char **"?

I think you are right to prefer const to avoid overwriting what we
should not.
> 
> [1] - http://open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
> [2] -
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf [3]
> -
> http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Warnings-and-Errors.html#Warnings-and-Errors
> 


- -- 
Rafaël Carré
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIB4A7YWCeGMCv8Q8RArT4AJ0XFxIB4wQrkOSwzjPHOvAlCC0ClgCfc4l/
rxsdgoJ0q0LB1B9/ImAzuIY=
=Gtn+
-----END PGP SIGNATURE-----