On Friday, 04 March 2005 at 15:32, Aaron Crane wrote: > Brendan Cully writes: > > I don't suppose you could dig a little further into exactly what's > > causing 'open' to get rewritten? > > (Sorry for the late response -- I've been rather ill recently.) thanks for the interesting response. > This sort of situation (a struct containing a function pointer named > after a standard function) tends to bite people fairly often. Defining > the struct doesn't cause a problem: yeah, one of the things that stopped me from just sitting down and renaming everything was the fact that DB4 also uses an 'open' function pointer, so I figured they must have solved the problem. > Fixes? Renaming the members of the struct is probably the best option. > > There's no point trying to find a compilation mode on some particular > combination of OS and compiler which doesn't trigger this behaviour, > because any other implementation could do the same thing. maybe so. It does seem a little ugly to hack in some solaris 8 define. > Another possibility is to > > #undef open > > (and so on for other such names) when defining the struct. This leads > to nasty behaviour, though; a file that does I think this is definitely too dangerous. > The only other option is unpleasant: change all calls to look like this: > > struct s *p = ...; > int fd = (p->open)(name, mode); > (p->close)(fd); > > This has the simple syntactic effect of preventing the calls from > looking like calls to function-like macros -- but at the high cost of > obscuring every single call made through such a struct, not to mention > the difficulty of remembering to do this. I actually don't mind this version. In a way I like it better than the global rename, even though it's about the same amount of work. It makes me feel like the namespace is a little less polluted :) But maybe I'll wait for a couple more votes before getting a cup of tea and sitting down with emacs for a little search and replace.
Attachment:
pgpZGxgAiYlMA.pgp
Description: PGP signature