From: David Malcolm <dmalcolm@redhat.com>
To: DJ Delorie <dj@redhat.com>
Cc: gcc-patches@gcc.gnu.org, binutils@sourceware.org
Subject: Re: [PATCH 08/16] libiberty.h: Provide a CLEAR_VAR macro
Date: Tue, 02 Jun 2015 01:39:00 -0000 [thread overview]
Message-ID: <1433207798.12727.49.camel@surprise> (raw)
In-Reply-To: <201506012147.t51Ll08P015579@greed.delorie.com>
On Mon, 2015-06-01 at 17:47 -0400, DJ Delorie wrote:
> > +/* Fill an lvalue with zero bits. */
> > +#define CLEAR_VAR(S) \
> > + do { memset (&(S), 0, sizeof (S)); } while (0)
>
> Hmmm... I don't see the point in this. The macro is almost as long as
> a bare memset() would be, and replaces a well-known function with
> something unknown outside this project. It neither hides a bug in an
> OS nor provides a common way to handle a difficult task across
> platforms.
Thanks for looking at this.
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.
There are a couple of ways to mess up such code; consider:
memset (&statement_list, 0, sizeof (statement_list));
memset (&stat_save, 0, sizeof (statement_list));
where a bug is hiding: the 2nd memset is using the wrong sizeof, leading
to only part of it being zeroed. Having a macro for this makes the code
shorter:
CLEAR_VAR (statement_list);
CLEAR_VAR (stat_save);
and thus more reliable (my eyes glaze over looking at all the memsets in
the more involved examples).
There's probably another way to mess this up, by forgetting the & on the
first param.
> You also do NOT want to use memset to zero out a C++ structure that
> contains more than just "plain old data" - you could easily corrupt
> the structure's hidden data.
Are you thinking of vtables here, "public" vs "private", or of
inheritance? FWIW I'm only using this from within binutils, which AFAIK
is pure C (I'm new to binutils).
> 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; in the various foo_c_finalize () functions
in patches 10 and 12 I try to only use CLEAR_VAR for structs, and
instead spell out NULL etc for ptrs. Perhaps CLEAR_STRUCT () might be a
better name? 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)
Thanks
Dave
next prev parent reply other threads:[~2015-06-02 1:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 20:50 [PATCH 00/16] RFC: Embedding as and ld inside gcc driver and into libgccjit David Malcolm
2015-06-01 20:50 ` [PATCH 03/16] gcc: Use timevars within driver David Malcolm
2015-06-01 20:50 ` [PATCH 04/16] gcc: Don't keep reinitializing RTL David Malcolm
2015-06-01 20:50 ` [PATCH 09/16] libiberty.h: Provide CTIMER_PUSH/POP David Malcolm
2015-06-01 21:33 ` DJ Delorie
2015-06-02 22:05 ` Jeff Law
2015-06-01 20:50 ` [PATCH 06/16] gcc: driver: add timevars for as, collect2, ld David Malcolm
2015-06-01 20:50 ` [PATCH 01/16] gcc: Generalization of timevar API; add gcc_jit_timer interface David Malcolm
2015-06-01 20:50 ` [PATCH 05/16] gcc: driver: add g_driver singleton David Malcolm
2015-06-01 20:51 ` [PATCH 02/16] gcc: Embed the driver in-process within libgccjit David Malcolm
2015-06-03 6:07 ` Bert Wesarg
2015-06-01 21:10 ` [PATCH 13/16] ld/Makefile.am: Introduce a libld.la David Malcolm
2015-06-01 21:10 ` [PATCH 16/16] gcc: Hack up the arguments to the linker David Malcolm
2015-06-01 21:10 ` [PATCH 07/16] binutils: bfd: Implement bfd_uninit David Malcolm
2015-06-01 21:10 ` [PATCH 15/16] gcc: Use libgas and libld within the driver David Malcolm
2015-06-02 8:40 ` Richard Biener
2015-06-02 11:08 ` Trevor Saunders
2015-06-02 12:26 ` Richard Biener
2015-06-01 21:10 ` [PATCH 08/16] libiberty.h: Provide a CLEAR_VAR macro David Malcolm
2015-06-01 23:14 ` DJ Delorie
2015-06-02 1:39 ` David Malcolm [this message]
2015-06-02 2:24 ` DJ Delorie
2015-06-01 21:11 ` [PATCH 12/16] binutils: Introduce "ld_main" and state-purging within "ld" subdir David Malcolm
2015-06-01 21:11 ` [PATCH 10/16] binutils: Introduce "gas_main", and state-purging with "gas" subdir David Malcolm
2015-06-01 21:11 ` [PATCH 11/16] binutils: gas/Makefile.am: Add libgas.la David Malcolm
2015-06-01 21:30 ` [PATCH 14/16] gcc: Add CTIMER_PUSH/POP to gcc's copy of libiberty David Malcolm
2015-06-01 21:47 ` DJ Delorie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1433207798.12727.49.camel@surprise \
--to=dmalcolm@redhat.com \
--cc=binutils@sourceware.org \
--cc=dj@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).