Re: const fixes seek commit approval

On Mon, 26 Oct 1998, Havoc Pennington wrote:

> > But, my inclination is still that constant returns are more trouble
> > than they are worth - some support for this view can be found in the
> > standard C library, which is const-correct on the arguments, but not
> > on the returns.
> >
> OK, you have convinced me to be at least kind of neutral on the issue, and
> I want to go ahead and get the const args stuff in. So I will commit a
> const args patch tomorrow or so when I get back to a computer I can
> compile stuff on, if there are no objections by then. 
> One remaining issue, what do you think of this kind of return value:
> gtk_label_get(GtkLabel*, char** text);
> I changed this to const char**, as you might predict. Is this a return
> value or an arg for the purposes of redoing the patch? It looks to me like
> it has the disadvantages (and advantages) of each, sadly. Sigh. 

nope, don't change such occourancs to const gchar**, the same reasons as
for normal return values do apply here as well, it's even a little more
serious. for normal return values you need to

gchar *string = (gchar*) get_const_string ();

but when the string is passed by adress, you need an extra adress operator
which can easily be fogotten, especially by newbies:

gchar *string;
get_const_string ((gchar**) &string);

the requirement of this cast, just to convert from (const gchar**) to (gchar**)
is even more fatal, since the compiler is unable to perform additional checks of
wether it's actually gchar* or gchar** that's passed.

as an aside, the compiler warning produced in such a case goes along the
lines of
...passing argument 1 of `foo' from incompatible pointer type...
not even mentioning that it's actually const-issue that's going on here.

so the worst thing to do is converting gchar** args to const gchar** args,
especially if normal return values are already not fully const enforcing.

> Havoc


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