Re: Reflection and /proc

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Scott Lurndal writes:
> Albert D. Cahalan <acahalan@cs.uml.edu> wrote :
>>> Charles Cazabon writes:
>>>> Albert D. Cahalan <acahalan@cs.uml.edu> wrote:

>>>> SCO and *BSD doesn't mean 'everybody' -- Linux cannot expect to
>>>> flagrantly violate existing practice and have the rest of the
>>>> Unixen follow suit.
>>> 
>>> Oh please. Do you think Sun asks Compaq for permission to write
>>> something useful? Do you think IBM waits for The Open Group?
> 
> As a matter of fact, IBM is a very strong voice in the Open Group,
> and while they don't necessarily wait for them, they don't 
> violate existing practice either [well, there was the time they

So "they don't [...] wait". Linux hackers should not wait either.

>>>> Solaris, HP/UX, Digital Unix, AIX, et. al. are too commercially
>>>> important for Linux to ignore.
>>> 
>>> Sure... we should steal every feature they have, then add extensions.
>
> Ahh, embrace and extend - the microsoft mantra!
>
> (hopefully, you are not serious).

Why not? Feaures and extensions are generally good.

>>> ---------------- List of glibc misfeatures: ---------------
>>> 
>>> llseek() does not have a prototype; this intentional bug destroyed some
>>> people's filesystems when fsck ran 
>
> non-standard, non-portable function.  Subsumed by lseek64.  Should
> be deprecated when LFS support added.

CAn you read? Removal destroyed filesystems. That is, removal caused the
loss of gigabytes of data while users were trying to fix minor errors.
This is seriously bad.

The "non-standard, non-portable function" argument is crap. Nothing says
that we may only support lseek64. We can have both. Anyway, Sun has llseek.

Backwards compatibility is an issue that should be taken seriously.
Linux libc 5 provided llseek. There is no conflict with a standard.
(in that case, commercial UNIX would typically ignore the standard)

>>> fputs() does not return a useful value. Both Digital UNIX and Solaris
>>> return the number of characters printed. 
>
> non-standard and non-portable use of the return value for fputs.

Another crap argument, same as the above. The C library should not
attempt to cause crashes and erroneous output.

> Standard explicitly doesn't specify the return value of fputs
> because the two unix universes handled it differently. 

What two? BSD is not UNIX. Anyone who wants BSD should get the real thing.
It would be incredibly stupid to clone BSD, since BSD is already free.

> Therefore, no portable software can make use of the return value
> of fputs, ipso facto, the return value _is_ useless, and may as
> well be void.

So you see no reason why someone would want to port from Solaris
or Digital UNIX to Linux? Do you want to make it difficult?

>>> SysV shared memory IPC is messed up. The struct ipc_perm members key
>>> and seq were renamed to __key and __seq This is incompatible with
>>> libc 5, AIX, and Solaris, Digital UNIX, etc. Some apps won't even
>>> compile anymore because glibc doesn't define SEMMSL and other SysV
>>> IPC related constants. (and they left the UID as a 16-bit value too) 
> 
> SEMMSL has never been a user-visible identifier on any version
> of unix, a great shortcoming by the way.

So we could fix that great shortcoming. Actually, we have a
compatibility screw up here. Linux libc 5 had it.

> All the configurable
> values for the sem, shm and msg subsystems should be exported
> via the 'sysconf()' API, while no standard exists for this, it
> would be a viable extension.

Good idea; we should do both.

> the key and seq members of the ipc_stat structure are private to
> the implementation

Wrong: Solaris, Digital UNIX, AIX, and our own libc 5 support it.
It seems only glibc is hostile to developers.

> and may not be used by portable applications.

Here you go again... This is not a reason why we shouldn't support
the feature. Shall we remove snprintf() and bcopy()? I think not!

>>> Almost everything must be compiled with -D_GNU_SOURCE, including
>>> non-GNU software. The namespace logic is backwards; one should
>>> specify POSIX to get a plain, bland, vanilla (nearly useless) namespace. 
> 
> Both POSIX and the Open Group have a very clear idea of how to 
> compile portable applications without namespace pollution.  
> (-D_POSIX_C_SOURCE=2 for posix, and -D_XOPEN_SOURCE (which is required
> to implicitly define -D_POSIX_SOURCE -D_POSIX_C_SOURCE) for X/Open
> extensions to the POSIX requirements.
> 
> Most implementations provide the rich native API as the default
> API and require the application writer to specify that a restricted
> compilation environment is required. 

Yes, this is what people like and expect.

> However, it is the implementation's choice which namespace to 
> provide as the default namespace. 

I know, but some choices are just bad.

> In my opinion the default should ensure portability and that
> extra work by the application engineer should be required to
> utilize implementation-specific features.

If I wanted a compliance tester, I would have downloaded one from
The Open Group. They have one on their web site.

I don't want a compliance tester.
-
Linux-future: thinking about the future of the Linux kernel
Archive:      http://humbolt.nl.linux.org/lists/
Wish list:    http://users.ox.ac.uk/~mert0236/linux-future.html