From: Junio C Hamano <gitster@pobox.com>
To: "David Syzdek" <syzdek@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9
Date: Sun, 26 Oct 2008 23:17:45 -0700 [thread overview]
Message-ID: <7v1vy2imt2.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <9a0027270810262246i56cf5515l5fa0875f91d90a7a@mail.gmail.com> (David Syzdek's message of "Sun, 26 Oct 2008 21:46:20 -0800")
"David Syzdek" <syzdek@gmail.com> writes:
> On Sun, Oct 26, 2008 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> I have a stupid question.
>>
>> Would it be a more appropriate improvement to do it like this:
>>
>> ifdef USE_THIS_AS_UINTMAX_T
>> BASIC_CFLAGS += -Duintmax_t="$(USE_THIS_AS_UINTMAX_T)"
>> endif
>>
>> and then add a section for FreeBSD 4.9-SECURITY like this:
>>
>> ifeq ($(uname_R),4.9-SECURITY)
>> USE_THIS_AS_UINTMAX_T = uint32_t
>> endif
>>
>> That way, an oddball 64-bit machine can use uint64_t here if it wants to,
>> possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).
>>
>
> Your suggestion provides more flexibility for other environments. I
> was making the assumption that 64-bit systems would define uintmax_t,
> however in retrospect that would be unwise.
> Would you like me to resubmit the patches with your modifications?
Actually there was a reason why I said this was a "stupid" question. I
think your assumption on 64-bit platforms would hold in practice, and my
suggestion could be an unnecessary overengineering. If nobody knows of a
system that would benefit from such a generalization, your original patch
would be better, partly because I think:
(1) USE_THIS_AS_UINTMAX_T is just for demonstration of concept and is a
terrible name we cannot possibly use in our Makefile. We have to
spend brain cycles to come up with a better name; and
(2) It may be tricky to come up with autoconf macros to determine what to
set USE_THIS_AS_UINTMAX_T to.
As a slightly unrelated aside, I find it somewhat unfortunate that the
conditional says "4.9-SECURITY", which is a bit too explicit and specific.
to my taste. I do not know how FreeBSD versioning scheme works, but
wouldn't your change work equally well for 4.9-RELEASE or 4.11-RELEASE?
I suspect that you would want to say "$(uname_R) that begins with '4.' or
smaller needs this workaround", as strtoul(3) manual page seems to appear
first in FreeBSD 5.0-RELEASE (but not found in FreeBSD 4.11-RELEASE).
next prev parent reply other threads:[~2008-10-27 6:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-26 11:52 [PATCH] Add support for uintmax_t type on FreeBSD 4.9 David M. Syzdek
2008-10-27 5:30 ` Junio C Hamano
[not found] ` <9a0027270810262239r311074m51d382bdd95fd0dc@mail.gmail.com>
2008-10-27 5:46 ` David Syzdek
2008-10-27 6:17 ` Junio C Hamano [this message]
2008-10-27 13:23 ` David Syzdek
2008-10-28 4:14 ` Junio C Hamano
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=7v1vy2imt2.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=syzdek@gmail.com \
/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.