[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] canonicalize_file_name

From: Neal H Walfield
Subject: Re: [patch] canonicalize_file_name
Date: Thu, 16 Aug 2001 16:29:03 +0200
User-agent: Mutt/1.3.18i

> > -static PedDevice*  devices = NULL;
> > +static PedDevice*  devices;
> I'm not applying that, until I get a legal guarantee (*grin*) that
> this is safe.  Why don't the gcc ppl just put this in zero memory,
> if they know it's zero?  This is a gcc bug, as far as I'm concerned.

I will not bother quoting you C99 as Matt has already done this.
However, to resummerize, globals and statics are guaranteed to be
initialized to 0.

So, what is the argument for not doing explicit initialization?  If you
initialize data, it goes in the .data section of an ELF executable.  If
you do not (and let it take the default value of 0), it goes in the .bss
section.  gcc will not move symbols between the two sections; this is a
Good Thing, system tools often have a good reason for being sure that
data goes in the .data section and not the .bss section.

As .data takes log(N) space and .bss takes log(1) space, it is better to
try to stuff as much in the .bss as possible.

People sometimes make the argument that gzip will handle this, however,
this is wrong as the zeroed data is not necessarily grouped together in
the .data section.  Additionally, they make the claim that this is
confusing.  It is not confusing if you know the rules; I teach this to
my computing 1 students.  Finally, save the world a few kilobytes.
Especially if you are a system utility as you have claimed you want it
to be on GNU/Linux and how I am making it on GNU/Hurd.

Attachment: pgpdGc0GfVJOg.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]