On Tuesday 20 May 2008 09:15, Bernhard Fischer wrote: > >Attached patch instroduces smallint type, and uses it > >for flag variables. It results in size reduction > >ont only for bss, but text too: > > > > text data bss dec hex filename > >- 648 4 24 676 2a4 > >libc/misc/internals/__uClibc_main.o > >+ 645 4 21 670 29e > >libc/misc/internals/__uClibc_main.o > >- 129 0 4 133 85 libc/termios/tcgetsid.o > >+ 126 0 1 127 7f libc/termios/tcgetsid.o > > > >because "flag_var = 1" is a smaller instruction now. > >Size in smallint can be set per-architecture. > > > >I am a bit unsire I picked suitable include files to put > >new definitions in. > > > >Can someone eyeball the patch? > >-- > >vda > > >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. >From past experience, gcc *can be* stupid. On i386, it aligns explicitly defined string arrays to 32 bits. (That's why bbox has ugly ALIGN1 macro). At least some versions of gcc were aligning any array bigger than 32 bytes to 32 bytes. Yes, that's BYTES, not BITS. I can easily imagine that on some architecture gcc may have 32-bit bool. It may be dictated by ABI or gcc may just be stupid again. I'd prefer to not being constrained by gcc's choice, but to make this choice independently from gcc. What do you think? -- vda _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
