Re: [PATCH] alloc.c: remove alloc_raw_commit_node() function

[Jeff King <peff@peff.net>]

On Wed, Jun 18, 2014 at 11:30:50PM +0100, Ramsay Jones wrote:

> So, the patch below is a slight variation on the original patch.
> I'm still slightly concerned about portability, but given that it
> has been at least a decade since I last used a (pre-ANSI) compiler
> which had a problem with this ...

For a while some people were compiling git with pretty antique
compilers, but I do not know if that is the case any more (Junio noted
recently that we have had trailing commas on arrays and enums in
builtin/clean.c for the past year, and nobody has complained).

Maybe those systems have all died off, or maybe those people only
upgrade every few years, and we are due for an onslaught of portability
fixes soon. :)

> [I have several versions of the C standard that I can use to check
> up on the legalise, but I'm not sure I can be bothered! ;-) ]

It was actually pretty easy to find. I only have C99, but "empty macro
arguments" are listed as one of the changes since C89 in the foreward.

> diff --git a/alloc.c b/alloc.c
> index eb22a45..5392d13 100644
> --- a/alloc.c
> +++ b/alloc.c
> @@ -18,9 +18,12 @@
>  
>  #define BLOCKING 1024
>  
> -#define DEFINE_ALLOCATOR(name, type)				\
> +#define PUBLIC
> +#define PRIVATE static
> +
> +#define DEFINE_ALLOCATOR(scope, name, type)			\

I am not sure offhand whether this is more portable or not (it would
depend on order of macro expansion, and I am not brave enough to read
through the preprocessor section of the standard carefully). Quick
reading online suggests that it's OK, but that an extra level of macro
expansion would not be. And of course the Internet is never wrong. :)

I'm inclined to go with it, and deal with it later if we get a
portability complaint (at which point we are no worse off than we are
right now).

-Peff