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".
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
On Mon, Nov 19, 2001 at 05:32:16PM -0800, John Alvord wrote:
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.
While it isn't a bad idea to isolate as much machine dependent code as possible in a few well publicised files, I think you need to be careful not to get carried away. Wine has done a fairly good job at this.
What I questioned was the criticism that FreeBSD was guilty of namespace pollution. Alexandre isn't the only wine developer who made this statement (check usenet). The header files in question are implementation dependent and can contain any variable name or #define or typedef. The fact is that both wine and FreeBSD have struct thread in implementation header files. AFAICT, neither is incorrect. But, to have a wine developer emphatically state that FreeBSD needs to fix its system header files is somewhat surprising. Why is it surprising to me? Because this reminds me a company here in Seattle.
On Mon, 19 Nov 2001 20:28:35 -0800, Steve Kargl sgk@troutmask.apl.washington.edu wrote:
On Mon, Nov 19, 2001 at 05:32:16PM -0800, John Alvord wrote:
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.
While it isn't a bad idea to isolate as much machine dependent code as possible in a few well publicised files, I think you need to be careful not to get carried away. Wine has done a fairly good job at this.
What I questioned was the criticism that FreeBSD was guilty of namespace pollution. Alexandre isn't the only wine developer who made this statement (check usenet). The header files in question are implementation dependent and can contain any variable name or #define or typedef. The fact is that both wine and FreeBSD have struct thread in implementation header files. AFAICT, neither is incorrect. But, to have a wine developer emphatically state that FreeBSD needs to fix its system header files is somewhat surprising. Why is it surprising to me? Because this reminds me a company here in Seattle.
If FreeBSD polutes name space with struct user, then surely wine also polutes name space also... albeit with less impact.
john
On Tue, 20 Nov 2001, John Alvord wrote: [...]
If FreeBSD polutes name space with struct user, then surely wine also polutes name space also... albeit with less impact.
Wine does not pollute the namespace because the 'struct thread' is not public. It is an internal structure defined in an internal header.
I usually favor the defensive approach which distrusts outside headers and tries to avoid using structure names that are likely to conflict. But we dodged the bullet for this time so I think it's best to wait till the next to decide what to do. The worst that can happen is a big rename which is easy enough to do anyway.
The only way Wine can pollute the namespace is with regard to Winelib applications. So that's if Wine symbols are defined in a Windows header and not protected by an '#ifdef __WINE__'. For instance defining GETBASEIRQ in 'include/winbase.h' is namespace pollution. Using 'USE_MSVCRT_PREFIX' in the msvcrt headers is namespace pollution too though it is of a much more limited and necessary/useful nature. Note that this also depends which version of the Windows headers you take as a reference.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
-
Alexandre Julliard -
Francois Gouget -
John Alvord -
Steve Kargl