This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Remove all traces of reg_char.


On Wednesday 18 April 2012 23:32:49 Carlos O'Donell wrote:
> On Wed, Apr 18, 2012 at 7:23 PM, David Miller <davem@davemloft.net> wrote:
> > From: Roland McGrath <roland@hack.frob.com>
> > Date: Wed, 18 Apr 2012 15:13:26 -0700 (PDT)
> > 
> >> The original intent seems to have been what {,u}int_fast8_t is for.
> >> So why not use that?
> > 
> > I would say because, like reg_char, they seem utterly useless.
> > 
> > Nobody overrides them just like nobody overrides reg_char.
> 
> The perfect is the enemy of the good. Your patch is a step forward. If
> we think using {u}int_fast8_t is a win then we can do that work, but
> with an eye towards the entire codebase and with experimental evidence
> that it yields measurable performance improvements. As it stands
> today, I agree that some types in the standard are a bit weird... like
> abstract art crafted behind the closed doors of a high end studio.

this predates me, so it's pure conjecture, but based on old code bases i've 
come across, this sounds more like a throw back to compilers that needed 
explicit help in picking variables to favor in registers over stack.  i'd 
naïvely say we've moved past that with modern versions of gcc, and any 
compiler set that needs these hints have much bigger problems that hacking 
string funcs in the C library can't overcome.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]