All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Hariom Verma via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Hariom Verma <hariom18599@gmail.com>
Subject: Re: [PATCH 1/1] git-compat-util.h: drop the `PRIuMAX` definition
Date: Mon, 25 Nov 2019 11:24:02 +0900	[thread overview]
Message-ID: <xmqq1rtwzoal.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20191124170643.GA16907@sigill.intra.peff.net> (Jeff King's message of "Sun, 24 Nov 2019 12:06:43 -0500")

Jeff King <peff@peff.net> writes:

> On Sun, Nov 24, 2019 at 01:09:23PM +0000, Hariom Verma via GitGitGadget wrote:
>
>> From: Hariom Verma <hariom18599@gmail.com>
>> 
>> Git's code base already seems to be using `PRIdMAX` without any such
>> fallback definition for quite a while (75459410edd (json_writer: new
>> routines to create JSON data, 2018-07-13), to be precise, and the
>> first Git version to include that commit was v2.19.0).
>> 
>> Therefore it should be safe to drop the fallback definition for
>> `PRIuMAX` in `git-compat-util.h`.
>
> I noticed this recently, too, and wondered if it was time for a cleanup.

While I agree with the conclusion, I do not think I agree with the
above "Therefore (implying that the lack of need for fallback
PRIdMAX means the same for PRIuMAX) it should be safe" as a good
justification.  That reasoning assumes that the outside world is
much saner than us.  We thought PRIuMAX fallback necessary while a
counterpart for PRIdMAX unneeded---the outside world could have made
a similar mistake and in the opposite way (i.e. only defined PRIdMAX
while leaving PRIuMAX undefined).

But I do agree with the alternative justification in the following
two paragraphs you have given, which are ...

> We do sometimes get portability reports more than a year after the
> problem was introduced. But I think this one is pretty safe. PRIuMAX is
> in C99, and we've been picking up other C99-isms without complaint.
>
> I was curious what system originally spurred this. The PRIuMAX
> definition was originally added in 3efb1f343a (Check for PRIuMAX rather
> than NO_C99_FORMAT in fast-import.c., 2007-02-20). But it was replacing
> a construct that was introduced in 579d1fbfaf (Add NO_C99_FORMAT to
> support older compilers., 2006-07-30), which talks about gcc 2.95.
> That's pretty ancient at this point.

... these.

> This part of the patch looks obviously correct. :) But...
>
>>  #ifndef SCNuMAX
>>  #define SCNuMAX PRIuMAX
>>  #endif
>
> Can we likewise ditch the fallback definition for SCNuMAX? And PRIu32,
> etc? It seems likely any platform would either have all of them or none.

I guess that's also a C99-ism that we can use?

Thanks, both.

  parent reply	other threads:[~2019-11-25  2:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-24 13:09 [PATCH 0/1] git-compat-util.h: drop the PRIuMAX definition Hariom Verma via GitGitGadget
2019-11-24 13:09 ` [PATCH 1/1] git-compat-util.h: drop the `PRIuMAX` definition Hariom Verma via GitGitGadget
2019-11-24 17:06   ` Jeff King
2019-11-24 17:40     ` Carlo Arenas
2019-11-24 20:15       ` Carlo Arenas
2019-11-25  2:24     ` Junio C Hamano [this message]
2019-11-25  2:45       ` Junio C Hamano
2019-11-25  9:34         ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq1rtwzoal.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=hariom18599@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.