[Swan-dev] type_t, type() and TYPE() in initializers

[Andrew Cagney]

Hugh,

I'm sure this has come up before -  the discussion concluded that a
cast within a static initializer probably isn't technically static.

Through trial and error (read, being repeatedly pinged for the same
mistake on IRC cf eb3ba97984910933b3ce9ff3155c2932b48597a0), I've
found the following works best:

 - lower case function or variable - here chunk(), empty_chunk, ... -
use this in all dynamic code
-  upper case macro - here CHUNK(), EMPTY_CHUNK, ... - use this in all
static code

When I tried to cast something like EMPTY_CHUNK so that it, instead of
empty_chunk, could be used (a foolish premature optimisation on my
part), I was invariably forced to either:

- define a further macro with no cast - above avoids needing to do this
- or hard-wire those cases - as has happened here - defeating the
point of the abstraction

I don't think performance and/or static analysers are an issue:

 - given their price, I'd be really surprised if a static analyser,
which looks at the entire code base, couldn't figure out that:
  return empty_chunk;
and
  return (chunk_t) { NULL,0, }
are the same

- pluto spends huge amounts of time executing assembler computing DH
and RSA,, the above is in the wash

OTOH,  I can print empty_chunk (but not EMPTY_CHUNK) and can reliably
breakpoint and step over a chunk() function (but not the alternatives,
at least not reliably)

Andrew

PS: CHUNK() wasn't a bug, it just wasn't used


On Fri, 18 Jan 2019 at 11:08, D. Hugh Redelmeier
<hugh at vault.libreswan.fi> wrote:
>
> New commits:
> commit d451f77d58f00986bb0605d4948be67a26385b31
> Author: D. Hugh Redelmeier <hugh at mimosa.com>
> Date:   Fri Jan 18 10:58:57 2019 -0500
>
>     make older GCC's happy
>
>     All these were prompted by diagnostics from GCC 4.8.5.  They probably
>     matter for other GCCs.
>
>     - GCC does not consider EMPTY_CHUNK a constant: don't use it as a
>       static initializer.
>
>     - GCC doesn't completely understand the way we initialized a
>       sub-struct field in a struct initializer.  Rewrite in a way that it
>       does understand.
>
>     - GCC had stricter field initialization enforcement.  Initialize fields
>       uselessly to silence it.
>
> _______________________________________________
> Swan-commit mailing list
> Swan-commit at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-commit