public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

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