On Wed, 2007-12-05 at 12:56 +0100, Mathias Hasselmann wrote: > Am Mittwoch, den 05.12.2007, 11:17 +0100 schrieb Mathieu Lacage: > > On Wed, 2007-12-05 at 09:28 +0100, Alexander Larsson wrote: > > > On Tue, 2007-12-04 at 15:59 -0500, Morten Welinder wrote: > > > > > I added an extra check for ->write != NULL in the splice case (because > > > > > write() already did that) and commited. > > > > > > > > I would be to avoid having struct members called write. That is a > > > > reserved > > > > symbol and if the C library decides to use a macro you will have some > > > > very > > > > interesting effects. > > > > > > Oh, yeah. Maybe we should rename it to something like _write? > > > > > > What other symbols can be macros like this? close? read? > > > > Pretty much everything, yes. I doubt it makes any sense to try to > > protect yourself from such stupidity. > > Specially as you can use #undef in your C code, when stuck with a > platform doing such stupidities...
Thats fine inside glib, but if you export these symbols in public headers you're forcing all applications to do said #undef:s. And such stupid platforms include linux and glibc. Only recently samba had to change a structure member name from close to close_fn due to this, and I had to handle the fallout in gnome-vfs. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list