vda.linux at googlemail.com
Sun Jun 1 20:53:15 UTC 2008
On Sunday 01 June 2008 20:02, Khem Raj wrote:
> > > >diff -d -urpN uClibc.1/libc/termios/tcgetsid.c uClibc.2/libc/termios/tcgetsid.c
> > > >--- uClibc.1/libc/termios/tcgetsid.c 2008-05-19 16:23:16.000000000 +0200
> > > >+++ uClibc.2/libc/termios/tcgetsid.c 2008-05-20 00:03:31.000000000 +0200
> > > >@@ -34,7 +34,7 @@ tcgetsid (fd)
> > > > pid_t pgrp;
> > > > pid_t sid;
> > > > #ifdef TIOCGSID
> > > >- static int tiocgsid_does_not_work;
> > > >+ static smallint tiocgsid_does_not_work;
> > >
> > > For cases like this i prefer to just use a bool.
> > Yeah, sounds logical. I'd do this too, but I don't have sufficient faith
> > in gcc not being stupid.
> In my opinion using bool is right thing to do and less error-prone on
> userside. At least compilers will do it consistent even if wrong.
> btw the you did not consider the architectures which do not define their
> own smallint in wordsize.h on such arches the definition will come from
Yes, it was intended. Do you want it to be changed so that compile fails
if unistd.h is mistakennly not included?
> libc/misc/fnmatch.c change would require to include unistd.h
> so that it will also get definition for other arches. As far as I see
> only x86 defines smallint as of now.
> btw saving three bytes in size is fine. Did you also consider/measure
> the performance hit? Now a days accessing int is much faster and I would
> consider this a better trade-off than size.
I thought that uclibc's goal was smaller code size.
Anyway, with attached test program I am getting:
# gcc -Os t.c
char reads: 1469029 us
int reads: 1441760 us
It measures the time it takes to sum up bytes:
addb buf+8, %al
addb buf+12, %al
addb buf+16, %al
addb buf+20, %al
addb buf+24, %al
addl buf+8, %eax
addl buf+12, %eax
addl buf+16, %eax
addl buf+20, %eax
addl buf+24, %eax
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1531 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20080601/37777e3c/attachment-0002.c
More information about the uClibc