Re: [PATCH v3 10/21] pack-bitmap: add support for bitmap indexes

Jeff King [off-list ref] writes:

I do wonder if at some point we should revisit our "do not use any
C99-isms" philosophy. It was very good advice in 2005. I don't know how
good it is over 8 years later (it seems like even ancient systems should
be able to get gcc compiled as a last resort, but maybe there really are
people for whom that is a burden).

Well, we are not kernel where being able to precisely control
generated machine code matters and enforcement of acceptable
compiler versions to achieve that goal is warranted, so I'd prefer
to avoid anything that tells the users "go get a newer gcc".

There are certain things outside C89 that would make our code easier
to read and maintain (e.g. named member initialization of
struct/union, cf. ANSI C99 s6.7.9, just to name one) that I would
love to be able to use in our codebase, but being able to leave an
extra comma at the list of enums is very low on that list.  Other
than making a patch unnecessarily verbose when you introduce a new
enum and append it at the end, I do not think it hurts us much (I
may be missing other reasons why you may want to leave an extra
comma at the end, though).

Even that problem can easily be solved by having the "a value of
this enum has to be lower than this" at the end, e.g.

        enum object_type {
                OBJ_BAD = -1,
                OBJ_NONE = 0,
                OBJ_COMMIT = 1,
                OBJ_TREE = 2,
                OBJ_BLOB = 3,
                OBJ_TAG = 4,
                /* 5 for future expansion */
                OBJ_OFS_DELTA = 6,
                OBJ_REF_DELTA = 7,
                OBJ_ANY,
                OBJ_MAX
        };


which will never tempt anybody to append at the end, causing the
patch bloat.

On Mon, Dec 02, 2013 at 12:36:34PM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

I do wonder if at some point we should revisit our "do not use any
C99-isms" philosophy. It was very good advice in 2005. I don't know how
good it is over 8 years later (it seems like even ancient systems should
be able to get gcc compiled as a last resort, but maybe there really are
people for whom that is a burden).

Well, we are not kernel where being able to precisely control
generated machine code matters and enforcement of acceptable
compiler versions to achieve that goal is warranted, so I'd prefer
to avoid anything that tells the users "go get a newer gcc".

Sorry, I was not very clear about what I said. I do not think "go get a
newer gcc" is a good thing to be telling people. But I wonder:

  a. if there are actually people on systems that have pre-c99 compilers
     in 2013

  b. if there are, do they actually _use_ the ancient system compiler,
     and not just install gcc as the first step anyway?

In other words, I am questioning whether we would have to tell anybody
"go install gcc" these days. I'm not sure of the best way to answer that
question, though.

There are certain things outside C89 that would make our code easier
to read and maintain (e.g. named member initialization of
struct/union, cf. ANSI C99 s6.7.9, just to name one) that I would
love to be able to use in our codebase, but being able to leave an
extra comma at the list of enums is very low on that list.

Yes, I can live without trailing commas. I was musing more on the
general issue (of course, we don't _have_ to take C99 as a whole, and
can pick and choose features that even pre-C99 compilers got right, but
I was wondering mainly when it would be time to say C99 is "old enough"
that everybody supports it).

-Peff