Re: [xml] Few Casts

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 :-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]