lkml.org 
[lkml]   [1998]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: OFFTOPIC: e2fsprogs and +2Gb partitions
On Sat, Jun 13, 1998 at 06:19:36PM +0200, Ulrich Drepper wrote:
> Andi Kleen <ak@muc.de> writes:
>
> > One thing I would wish for a _LINUX_SOURCE would be the definition of
> > the "linux standard" __u{64,32,16,8} / u{64,32,16,8} /
> > s{64,32,16,8} / __s{64,32,16,8} typedefs.
>
> Did you ever thought about namespace problems? These names are one of
> the reasons many programs contain #ifdef linux or exist in Linux
> variants.

The __ variants are 100% name space clean. If they're all ifdefed
with _LINUX_SOURCE then the name space problem is moot anyways - _GNU_SOURCE
adds name space polution, _BSD_SOURCE adds name space pollution - why is
Linux so special?

If you want to be anal you can make the __ variants depended on _LINUX_SOURCE
and the non-__ vartants dependent on another define (lets say
_LINUX_LEGACY_SOURCE)

>
> > No, switching the kernel code to C9x style type defines is not an option
> > neither.
>
> Is this a sacrilege? Or are the types above now the types chosen by
> the Gods and all the rest of the world has to follow? Why not try it
> once the other way round and follow what the rest of the world does?
> This need not even be done in the kernel sources, only in the headers.
> The asm/types.h file simply could define both types.
>
> A very easy solution to this problem is to have in the application
> code a header which defines these types. Not including these types is
> again the only mean to make sure these incompatible types are not
> generally used.

I think this is a bad hack. Do you really want to duplicate kernel includes
in all kinds of packages? This gives bad source control problems and makes
extending the kernel very difficult .

>
> How should an average programmer know that these types shouldn't be
> used. S/He will look throught the headers, see these types, they are
> defined for Linux and they are short and handy and so will use them.
> Voila, just another Linux specific program. If on the other hand
> these names are not available the correct types automatically will be
> used and the programs written by those programmers are automatically
> portable.

glibc should not be a exercise to punish programmers for some kinds of
sins - it should be a tool to get the job done.

If you don't supply these types programmers will duplicate kernel headers
instead (which is bad!) or define these types on their own (which is even
worse, because it makes porting to Alpha etc. very difficult).

And there exists a large body of code that uses these types, if you like
it or not. And sometimes we need to write Linux specific code, simply because
Linux has some interfaces that don't exist on other systems (for example
the netlink interface, the SO_FILTER extension Alan pointed out etc. etc.)

Also if you're mandating standards compliance so much - why does glibc define
so many non-standard GNU extensions then?


-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:1.235 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site