Re: [xml] Few Casts

["Igor Zlatkovic" <igor zlatkovic com>]

> xmlRealloc is a macro wrapper around xmlReallocLoc, which takes 'void *"
> as its first parameter, right?  wouldn't casting to 'void *' be clearer

Yes, casting to void* would have been cleaner.

> (the other looks like "casting away const", which would normally be ab
> Bad Thing).  Since realloc operations really do treat the target of the
> pointer as opaque, and therefore immutable, another option would be to
> change the signature of xmlReallocLoc to:
>
>   void* xmlReallocLoc(const void *ptr,size_t size, const char *file,
>                       int line);

No way, changing function's signatures in libxml usually breaks a half of
the world when you least expect it. GNOME and KDE desktops before all.

> but then, that looks silly. Does MSWin have the extra 'const' in the
> signature of its 'realloc'?  Or is the MS compiler parsing the const as
> applying to the outer pointer, instead of the inmost primitive?  In that

That doesn't matter. MS compiler won't implicitly remove the const from
anything without issuing a warning.

> case, we could create a typedef which forced the compiler to assign the
> constness to the correct spot:
>
>   typedef const xmlChar* xmlCharConstPtr;
>
> and then declare 'nameTab' with that typedef.  Or we could move the
> 'const' to between 'xmlChar' and '*', which should disambiguate to
> constness for VC++.  I think that this is actually more "correct", by
> the language definition, but it always looks odd to me:
>
>   xmlChar const* * nameTab;

That changes the meaning of the declaration. The one is a constant pointer,
the other a pointer pointing to a constant object.

All I wanted to do is remove the const explicitly so the compiler warning
goes away. This I did :-) Only if you have a platform on which my
machinations fail to compile or issue different warnings, then I'll revise.
But if everything is basically fine and you have a better, cleaner approach,
feel free to submit a patch :-)

Ciao,
Igor