Re: [evolution-patches] Fixes for compiler warnings about signedness



The question isn't about const-ness.  It's about signedness.

The following is perfectly valid:

char *name = g_strdup ("id");
xmlChar *xprop = xmlGetProp (node, (xmlChar*)name);

you don't have to put the "const" in the type for arguments, as its use
in argument lists is more a promise that the function won't modify it.
Return types are the only place where const is an issue for the consumer
of a library.

As for the original question, I guess I'm more in the "don't worry about
it" camp than some people, but if 0 warnings is the goal (and it's a
worthy goal, don't get me wrong) and code changes are what we're looking
at, I can see two options:

1. a utility function, something like "e_xmlGetProp (xmlNodePtr node,
gchar *name)", which does the correct casting for you.  Then just
globally replace all occurrences of xmlGetProp with that.

2. insert a cast at every call to xmlGetProp.

I'd lean more toward 1.  It's more easily automated (yay sed), makes it
clear what you're doing (and why) as you can document e_xmlGetProp, and
it also allows us to possibly get rid of the following pattern from
everywhere in evolution:

xmlChar *foo = xmlGetProp (...);
gchar *bar = g_strdup (foo);
xmlFree (foo);

as you can just have e_xmlGetProp return the g_strdup'ed value.

Chris

On Sat, 2006-01-07 at 15:34 +0100, Philip Van Hoof wrote:
> On Fri, 2006-01-06 at 13:33 +0100, Kjartan Maraas wrote:
> 
> > I'd like to get some thoughts from others to see how we can get rid of
> > these in a sensible manner.
> 
> By casting it. You, Kjartan, probably already know this (I don't know).
> But I'll put the explanation here for people who don't.
> 
> The library methods expect const char pointers because it's a way (for
> library developers) to 'promise' that they won't touch the char pointer
> (they won't write to it nor alter it).
> 
> Of course, using dirty casting tricks, they can still do that. But it's
> a form of convention (you can't nor shouldn't attempt to alter const
> variables, but it's a pointer . . . so by casting it you can fool the
> compiler).
> 
> That doesn't mean that you *need* to pass pure const char pointers. Just
> tell the compiler that it's okay, that you know what is happening (in
> essence, that you trust the library writer).
> 
> The case you mention expects a (const xmlChar*) where xmlChar is a
> "typedef unsigned char xmlChar". So, a "unsigned const char*" like, for
> example, a "string" encapsulated in double quotes.
> 
> xmlChar* xmlGetProp (xmlNodePtr node, const xmlChar * name)
> 
> If you pass it a normal (char*), it's still okay. The library programmer
> just promises you that he's not going to write to it. And you'll have to
> eventually deal with the pointer (for example freeing it in case it's an
> allocated one).
> 
> xmlDocPtr = /* etc */
> xmlNodePtr node = /* etc */
> 
> gchar *name = g_strdup ("id");
> const xmlChar *xatt = (const xmlChar*)name;
> xmlChar *xprop = xmlGetProp (node, xatt);
> gchar *prop = g_strdup ((const gchar*)xprop);
> xmlFree (xprop); /* but don't free xatt */
> 
> xmlFreeNode (node);  /* and/or */
> xmlFreeDoc (doc); /* etc */
> 
> Whether or not the strdup the xprop to prop might or might not be a
> necessity. It might depend on how strictly you want to separate GLib
> from libxml2. Short version: it doesn't really matter (this way means
> introducing an extra string duplication followed by a free of the
> original).
> 
> 
> 



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