Patches for FreeBSD 5.x compilation
jalvo at mbay.net
Tue Nov 20 10:31:52 CST 2001
On Mon, 19 Nov 2001 20:28:35 -0800, Steve Kargl
<sgk at 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 at winehq.com> wrote:
>> >Steve Kargl <sgk at 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
If FreeBSD polutes name space with struct user, then surely wine also
polutes name space also... albeit with less impact.
More information about the wine-devel