Re: [Dri-devel] createContext callback in libGL

[Michel <mi...@da...>]

On Fre, 2003-05-09 at 22:03, Leif Delgass wrote:
> On Fri, 9 May 2003, Ian Romanick wrote:
> 
> > Leif Delgass wrote:
> > > On Fri, 9 May 2003, Ian Romanick wrote:
> > > 
> > >>Given that, I see no point in adding a new entry 
> > >>point that will be 99% the same as the existing entry point.
> > > 
> > > But aren't you in undefined behavior territory when the parameter
> > > signatures differ between the function pointer and the function being
> > > called (even if they only differ in the presence of a final, extra
> > > parameter)?  We'd have a single entry point with mismatched signatures in
> > > libGL and driver_dri.so if one is old and the other is new, even if we
> > > check versions and pass NULL for fbconfig from libGL or avoid
> > > dereferencing fbconfig in the driver module (dereferencing it would cause
> > > a segfault if libGL doesn't pass the last param).  Is there any guarantee
> > > we won't get stack corruption?
> > 
> > Not on any system that I have ever encountered.  Things like printf kind 
> > of depend on that behavior working. :)
> 
> Well, va_lists are part of the language/library spec, but there's no '...'
> in the callback prototype (as there is in printf's).  You have to use
> va_arg() to get parameters from variable argument lists. I don't think
> you'd get a compiler warning about incompatible pointer types if
> mismatched prototypes were legal.  There may not a problem in practice
> with most implementations so long as you don't dereference an invalid
> parameter, but isn't it an implementation-dependant behavior?  Is there a
> guarantee that this won't break with some future gcc/glibc combination?

I shared your concerns at first, but isn't this covered by the C ABI?
I.e., if this works now but breaks later, the C ABI will have changed in
between, in which case binary compatibility is foobar anyway?


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer