svn commit: trunk/uClibc/libc/unistd

Bernhard Fischer rep.dot.nop at gmail.com
Sat Jun 7 15:42:13 UTC 2008


On Sat, Jun 07, 2008 at 07:39:54AM +0200, Denys Vlasenko wrote:
>On Friday 06 June 2008 14:50, Bernhard Fischer wrote:
>> On Thu, Jun 05, 2008 at 08:24:45PM -0700, vda at uclibc.org wrote:
>> >Author: vda
>> >Date: 2008-06-05 20:24:45 -0700 (Thu, 05 Jun 2008)
>> >New Revision: 22242
>> >
>> >Log:
>> >shrink getopt a bit by using smallints. Run tested (busybox testsuite)
>> 
>> I still think that this route is wrong.
>
>I somewhat agree in a sense that smallints should not be *abused*.
>They should be used only in the following cases:
>
>* variables are not on stack but in data or bss, or in rare cases
>  in a structure which is allocated many times (not typical
>  for libc code, but happens a lot in bbox)
>* variables are bool flags or enum-like values; not much of
>  arithmetic is done on them (+,-,bitshifts): on many arches
>  arith ops on narrow ints are bigger and/or slower.
>  (as opposed to loads/stores and bit tests. If on some arch
>  even loads/stores and bit tests are bigger, it should use
>  "smallints" which are just ordinary ints.
>
>I can commit a change which adds a comment with this text
>to codebase. Do you want me to do it?

Not needed for me, so no but thanks.

>> VRP knows the exact range of values a variable is in. -fnarrow-type
>> should deal with this for us, really.
>
>As soon as someone will do flag++ as a bastardized flag = 1
>or global_flag = bool_parameter_of_a_function,
>this will break.
>
>> fnarrow-types
>> Common Report Var(narrow_types,0) Optimization
>> Narrow variables to use the smallest possible type
>
>Nice.

if somebody would implement it, yes.

>> This would (, for non-public variables)
>
>Many variables will be "public" for compiler since they will be touched
>from several .o files within uclibc.

If they are hidden then they are not public, i think.



More information about the uClibc mailing list