On 19 Nov 2001 15:42:18 -0800, Alexandre Julliard julliard@winehq.com wrote:
Steve Kargl sgk@troutmask.apl.washington.edu writes:
Can you please explain how this is namespace pollution on the part of the OS? AFAIK, <sys/user.h> is not specified by any Standard (ISO C89, C90, or C99). <sys/user.h> can include any (unprotected) variable name.
Yes of course it can, but the fact that this isn't explicitly forbidden by some standard doesn't mean it's good practice or that it doesn't pollute the namespace. sys/user.h is also legally allowed to do "#define if else"; that doesn't make it a good idea.
If an application includes <sys/user.h>, then the application should be prepared to deal with conflicts.
Great, then you need to fix all applications every time someone feels like exporting a new symbol from user.h. Of course user.h is a pretty obscure header so it's no big deal, but it would be easier to avoid exporting stuff under such common names as "struct thread".
One way to dodge the name conflicts is to create a separate compilation unit, target platform dependent, which does the needed work and returns the dynamic information needed. That way it can use just the particular platform includes and none of the wine or windows includes. The wine code just calls "wine_get_userlen()" and the implementing code is target platform dependent.
john alvord