Re: Bonobo stream API mis-naming ...

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> 	It turns out ( despite this seeming to have caused no problem reports
> in Gnome 1.4 ), that using 'truncate' as an element of a virtual method
> table (eg.) is a serious problem:
> 
> 	http://bugzilla.gnome.org/show_bug.cgi?id=90551
> 
> 	Problem is - that the next API thaw when we could do this change is
> inconcievably far away. It's quite easy to change all the methods to
> include 'Bytes' or 'Stream' or some other bogus, redundant stuff so:
> 
> 	'readBytes', 'writeBytes', 'truncateStream' etc.
> 
> 	But that seems to suck quite badly;
> 
> 	The problem is ( on Solaris ) things like:
> 
> > grep '[^f]truncate.*truncate64' /usr/include/unistd.h 
> #pragma redefine_extname        truncate        truncate64
> #define truncate                        truncate64

It's unclear to me that there really is a problem here.

The '#pragma redefine_extname' stuff shouldn't touch structure members
at all if it is implemented sanely. Structure members are a different
namespace than symbol names.

And in the fallback case of the #define (used, I believe, for non-SunPro
compilers), the redefine is harmless. As long as the structure field
is in the same position, it doesn't matter what the compiler thinks
it is named. (*)

AFAIK, there is no idea that struct field names are 'reserved' by 
the C library; After all, if that was the case, then no new C 
library functions could ever be introduced, since they could conflict 
with existing names in applications.

Regards,
                                        Owen

(*) We have seen a few problems for GTK+ where compilers have 
    #define'ed common names to custom compiler keywords; but that
    is a much more rare and less reasonable practice.