Re: Bonobo stream API mis-naming ...

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> Hi Owen,
> 
> On Wed, 2002-08-21 at 17:47, Owen Taylor wrote:
> > > > 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.
> >
> > 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. (*)
> 
> 	Hmm; true - but I believe the issue is that if (for whatever reason)
> Bonobo.h is included, and subsequently unistd.h is included - when
> people do:
> 
> 	my_struct->truncate = my_impl;
> 
> 	Then they assign the 'truncate64' element, but when it was declared the
> #define was not there to mangle it horribly - so we get:
> 
> 	structure has no element 'truncate64' - depending on include order.
> 
> 	So - It seems to me to come down to the fact that we need to include
> every possible header that does this kind of mangling, for each platform
> at the top of Bonobo.h - which is possible; which headers are these ? is
> it just unistd.h ? is this a fix for all systems ? etc.

Ugh. Including system headers into library headers is somewhat
evil since it is a "always increasing" set; you can never remove
one. 

I think this problem is going to end up coming up little enough that
we can just tell people who are affected to fix their include order to
avoid it. It's really best practice, in any case, to always include
headers in the order of:

 A) System headers
 B) Library headers
 C) Application headers

Basically for exactly this reason ... library headers are in a better
position to work around problems in system headers than vice versa.

Regards,
                                        Owen