Re: Bug: on recent 32-bit-kernels uid_t is 16 Bit instead of 32 Bit

Frank Bergmann <[email protected]>
Newsgroups gmane.linux.lib.dietlibc
Message-ID <[email protected]>
In Thu, 3 Dec 2009, Felix von Leitner cum veritate scripsit :

> We used to include header files.
> Linus sent me an email saying I should not, so I stopped.

I guess this was *long* ago, wasn't it? I'm wondering if glibc does 
include linux/* stuff. Did the GNU people also get this email by Linus?
;-)

> The reason is that nobody has needed them yet.

Actually I did. :-)

> Supporting 32-bit uid and gid means adding backwards compatibility
> layers, which, frankly, nobody has volunteered to write so far.

But even if getpwname is dropped to libcruft it is still available. Using 
it will actually fail on systems with uids greater than 65535. Therefore 
it is a bug. If removing functions and pw structs may not be the best way 
there should be some attribute causing warnings at compile time.

> The development model of dietlibc is: do not implement things because
> someone might need it, only implement things someone actually needs.

But if something *is* implemented it should be done without nasty 
pitfalls.

> What kind of embedded platform do you have that really needs 32-bit
> uids?

Ooops! I'm on the wrong mailing list. I mixed up dietlibc and embedded 
libc. I thought I was using a libc implementation which is used more and 
more for applications on many linux desktop distributions. :-)



EDV Frank Bergmann                           Tel.     05221-9249753
LPIC-2 Linux Professional                    Fax      05221-9249754
Elverdisser Str. 25                          email    [email protected]
32052 Herford                                USt-IdNr DE237314606

-- 
Sending unsolicited commercial email to this address may be a violation
of the Washington State Consumer Protection Act, chapter 19.86 RCW.
Das Verschicken unverlangter kommerzieller email an diese Adresse ist
verboten (LG Traunstein, 2 HK O 3755/97 vom 14.10.1997, CR 1998, 171f).
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.