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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html