* [PATCH] Add support for uintmax_t type on FreeBSD 4.9 @ 2008-10-26 11:52 David M. Syzdek 2008-10-27 5:30 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: David M. Syzdek @ 2008-10-26 11:52 UTC (permalink / raw) To: git; +Cc: David M. Syzdek This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then uintmax_t is defined as uint32_t. This adds a test to configure.ac for uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY. Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net> --- Makefile | 3 +++ config.mak.in | 1 + configure.ac | 8 ++++++++ 3 files changed, 12 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 0d40f0e..bf6a6dc 100644 --- a/Makefile +++ b/Makefile @@ -931,6 +931,9 @@ endif ifdef NO_IPV6 BASIC_CFLAGS += -DNO_IPV6 endif +ifdef NO_UINTMAX_T + BASIC_CFLAGS += -Duintmax_t=uint32_t +endif ifdef NO_SOCKADDR_STORAGE ifdef NO_IPV6 BASIC_CFLAGS += -Dsockaddr_storage=sockaddr_in diff --git a/config.mak.in b/config.mak.in index b776149..c6558eb 100644 --- a/config.mak.in +++ b/config.mak.in @@ -39,6 +39,7 @@ NO_C99_FORMAT=@NO_C99_FORMAT@ NO_STRCASESTR=@NO_STRCASESTR@ NO_MEMMEM=@NO_MEMMEM@ NO_STRLCPY=@NO_STRLCPY@ +NO_UINTMAX_T=@NO_UINTMAX_T@ NO_STRTOUMAX=@NO_STRTOUMAX@ NO_SETENV=@NO_SETENV@ NO_UNSETENV=@NO_UNSETENV@ diff --git a/configure.ac b/configure.ac index d3b8bc3..d9de93f 100644 --- a/configure.ac +++ b/configure.ac @@ -415,6 +415,14 @@ AC_CHECK_FUNC(strlcpy,[ [NO_STRLCPY=YesPlease]) AC_SUBST(NO_STRLCPY) # +# Define NO_UINTMAX_T if your platform does not have uintmax_t +AC_CHECK_TYPE(uintmax_t, +[NO_UINTMAX_T=], +[NO_UINTMAX_T=YesPlease],[ +#include <inttypes.h> +]) +AC_SUBST(NO_UINTMAX_T) +# # Define NO_STRTOUMAX if you don't have strtoumax in the C library. AC_CHECK_FUNC(strtoumax,[ AC_SEARCH_LIBS(strtoumax,, -- 1.6.0.2.GIT ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9 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> 0 siblings, 1 reply; 6+ messages in thread From: Junio C Hamano @ 2008-10-27 5:30 UTC (permalink / raw) To: David M. Syzdek; +Cc: git "David M. Syzdek" <david.syzdek@acsalaska.net> writes: > This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then > uintmax_t is defined as uint32_t. This adds a test to configure.ac for > uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY. > ... > diff --git a/Makefile b/Makefile > index 0d40f0e..bf6a6dc 100644 > --- a/Makefile > +++ b/Makefile > @@ -931,6 +931,9 @@ endif > ifdef NO_IPV6 > BASIC_CFLAGS += -DNO_IPV6 > endif > +ifdef NO_UINTMAX_T > + BASIC_CFLAGS += -Duintmax_t=uint32_t > +endif 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 ;-). ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <9a0027270810262239r311074m51d382bdd95fd0dc@mail.gmail.com>]
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9 [not found] ` <9a0027270810262239r311074m51d382bdd95fd0dc@mail.gmail.com> @ 2008-10-27 5:46 ` David Syzdek 2008-10-27 6:17 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: David Syzdek @ 2008-10-27 5:46 UTC (permalink / raw) To: git On Sun, Oct 26, 2008 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote: > > "David M. Syzdek" <david.syzdek@acsalaska.net> writes: > > > This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then > > uintmax_t is defined as uint32_t. This adds a test to configure.ac for > > uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY. > > ... > > diff --git a/Makefile b/Makefile > > index 0d40f0e..bf6a6dc 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -931,6 +931,9 @@ endif > > ifdef NO_IPV6 > > BASIC_CFLAGS += -DNO_IPV6 > > endif > > +ifdef NO_UINTMAX_T > > + BASIC_CFLAGS += -Duintmax_t=uint32_t > > +endif > > 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? -- An earthquake wiped out Etchisketchistan today. -- Onion TV ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9 2008-10-27 5:46 ` David Syzdek @ 2008-10-27 6:17 ` Junio C Hamano 2008-10-27 13:23 ` David Syzdek 0 siblings, 1 reply; 6+ messages in thread From: Junio C Hamano @ 2008-10-27 6:17 UTC (permalink / raw) To: David Syzdek; +Cc: git "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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9 2008-10-27 6:17 ` Junio C Hamano @ 2008-10-27 13:23 ` David Syzdek 2008-10-28 4:14 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: David Syzdek @ 2008-10-27 13:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Sun, Oct 26, 2008 at 10:17 PM, Junio C Hamano <gitster@pobox.com> wrote: > "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). > The following should match against FreeBSD 4.x: FREEBSD_MAJOR := $(shell sh -c 'echo $(uname_R) |cut -d. -f1') ifeq ($(FREEBSD_MAJOR),4) NO_UINTMAX_T = YesPlease NO_STRTOUMAX = YesPlease endif Is the use of FREEBSD_MAJOR okay, or would another name be more appropriate? -- An earthquake wiped out Etchisketchistan today. -- Onion TV ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9 2008-10-27 13:23 ` David Syzdek @ 2008-10-28 4:14 ` Junio C Hamano 0 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2008-10-28 4:14 UTC (permalink / raw) To: David Syzdek; +Cc: Junio C Hamano, git "David Syzdek" <syzdek@gmail.com> writes: > The following should match against FreeBSD 4.x: > > FREEBSD_MAJOR := $(shell sh -c 'echo $(uname_R) |cut -d. -f1') > ifeq ($(FREEBSD_MAJOR),4) > NO_UINTMAX_T = YesPlease > NO_STRTOUMAX = YesPlease > endif > > Is the use of FREEBSD_MAJOR okay, or would another name be more appropriate? Other parts of the Makefile seems to do something like this: ifeq ($(shell expr "$(uname_R)" : '4\.'),2) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-10-28 4:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2008-10-27 13:23 ` David Syzdek
2008-10-28 4:14 ` Junio C Hamano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).