Peter Memishian wrote: > > > Can |#pragma redefine_extname| be nested in SUn Studio and gcc ? > > I don't really see how nesting per se would work since there's no way to > uncover the hidden definition (also, I presume you meant to specify the > arguments in the opposite order?)
No... I only used the wrong english word... what we really want is "overriding" and not "nesting". The trouble is that if we have a library function |stat()| and it's symbol is redirected via... -- snip -- #pragma redefine_extname __posix_stat stat -- snip -- ... to |__posix_stat()| and then the application includes a 2nd header which does redefine the function with... -- snip -- #pragma redefine_extname __gnu_stat stat -- snip -- ... erm... which symbol is used for a |stat()| call - |__posix_stat| or |__gnu_stat| ? > All that said, from what I can tell, > the behavior is unspecified if old_extname is redefined to be two > different new_extnames, and I wouldn't be surprised for the behavior to > vary (also, don't forget to consider lint). Should be easy to sidestep > the situation in a manner similar to header guards though. Just doing some #ifdef.../#endif will AFAIK not work since Solaris/GNU/etc. do not have a common naming standard for header markers (e.g. #ifndef _SYS_TIME_H_INCLUDED #define _SYS_TIME_H_INCLUDED /* header body */ #endif) and nothing exists which could be used as a "guard" at _symbol_ level. The GNU people "solve" this problem by using |#undef stat ; #define stat __gnu_stat| ... however this implodes if anything else uses this "trick", too... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL <currently fluctuating> (;O/ \/ \O;)
