This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 08/16] libiberty.h: Provide a CLEAR_VAR macro
- From: DJ Delorie <dj at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, binutils at sourceware dot org
- Date: Mon, 1 Jun 2015 21:39:39 -0400
- Subject: Re: [PATCH 08/16] libiberty.h: Provide a CLEAR_VAR macro
- Authentication-results: sourceware.org; auth=none
- References: <1433192664-50156-1-git-send-email-dmalcolm at redhat dot com> <1433192664-50156-9-git-send-email-dmalcolm at redhat dot com> <201506012147 dot t51Ll08P015579 at greed dot delorie dot com> <1433207798 dot 12727 dot 49 dot camel at surprise>
> FWIW I'm not in love with the name of the macro, but I find it useful.
> In the initial version of patches 10 and 12 (state purging within "gas"
> and "ld" subdirs) I didn't have this macro, and had about 30 memset
> invocations.
Another option is to save the state as it was initialized, and restore
it as needed. That way, structures that don't start off all zero will
get "reset" properly. In this case, you're just talking about a
simple assignment:
saved_vars = my_vars;
. . .
my_vars = saved_vars;
In addition to simplicity, the compiler will check the types for you
to make sure you don't goof up.
> Are you thinking of vtables here, "public" vs "private", or of
> inheritance?
Yes.
> FWIW I'm only using this from within binutils, which AFAIK is pure
> C (I'm new to binutils).
Ah, but you're putting the macro in libiberty, which *is* used by C++
files.
> > Also, pedantically speaking, "all bits zero" is not guaranteed to be
> > the same as float 0.0, double 0.0, or pointer (void *)0.
>
> The purpose of the code is to restore the state back to what it was when
> the library was first loaded;
That's not what you're doing, what you're doing is setting it to all
zero, even if the data was non-zero at the start.
> Also, if this isn't so much a libiberty thing (not being an
> OS-compatibility thing), is there a place to put it in internal
> support headers? (in the sense that this would be an implementation
> detail, used by both gas and ld)
bfd.h might be an option, since it's common to most binutils programs.