svn commit: trunk/uClibc/libc/unistd

Denys Vlasenko vda.linux at googlemail.com
Sat Jun 7 05:39:54 UTC 2008


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?

> 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.

> This would (, for non-public variables)

Many variables will be "public" for compiler since they will be touched
from several .o files within uclibc.
--
vda



More information about the uClibc mailing list