[Swan-dev] Add -std=c99 to the compiler flags?

[D. Hugh Redelmeier]

| From: Andrew Cagney <andrew.cagney at gmail.com>

| On 4 February 2015 at 15:33, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
| > | From: Andrew Cagney <andrew.cagney at gmail.com>

| > |     for (int i = 0; i < 10; i++) { ... }
| > |
| > | without -std=c99 I get a warning :-)

| > Why does gcc require a flag?  Is using c99 so remarkable that it cannot be
| > the default?  Is there any downside?  At least some things we already use
| > were introduced in C99.
| 
| The default for GCC (i.e, up to 4.x) is -std=gnu90 ("GNU dialect of
| ISO C90 (including some C99 features)").  That is why we get away with
| doing some things, but other things get warnings.

Surely they could add the for (int i... thing too.  It doesn't break
any existing program.

| > What other C99 features are worth using?
| >
| > - I think that we already use the struct and union member initializing
| >   syntax
| 
| GNU and C99 had different syntax, I believe we're using the new syntax.

Right.  That seems to be allowed by default.

| > - Variable Length Arrays (VLAs) have been made optional-to-support in the
| >   more recent standards so we should not use them.  Too bad: they could
| >   do what alloca was used for.
| 
| There's dogma arguing that we, as (what is the buzz phrase) an attack
| surface, should never allocate dynamic sized structures on the stack.

I don't that that is the reason.  I think it is that it was a
divergence from C++, and now C++ kind of takes the lead.

| The behaviour of inline also changed.  Specifically this case:
| 
| static __inline__ struct hash_desc *ike_alg_get_hasher(int alg)
| {
|         return (struct hash_desc *) ikev1_alg_find(IKE_ALG_HASH, alg);
| }

I try to avoid anything with __.  It's a danger sign.  Sometimes
needed.

What's changed here?

| (I'm guessing the intent is for this to be a strongly typed macro)

Yeah, probably.  Mind you, I look at it the other way: #define is a
poor man's inline, one with no typechecking.

| IMNSHO we shouldn't be using inline any way.  We're deluding ourselves
| if we think we can out wit the compiler: GCC will inline the things it
| likes regardless; and issue warning pointing out how we're wrong :-)

I use inline when I'm confused about our headers.  It has the merit of
a macro (can be defined, not just declared in a .h).  And yet it is
type safer.

I don't like it that I'm confused about our headers.  Some .h files
are available to all userland but contain things only for pluto, for
example.  That's bad.

Non-inline external functions are often hard to inline, depending on
the compiler architecture.

| > - <inttypes.h> I think we already use it
| 
| We should be using it.  Often we don't.

Clean up anything you stumble upon.  That's what I try to do.