[PATCH] Add support for uintmax_t type on FreeBSD 4.9

[PATCH] Add support for uintmax_t type on FreeBSD 4.9

[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

Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9

[Junio C Hamano]

"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 ;-).

Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9

[David Syzdek]

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

Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9

[Junio C Hamano]

"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).

Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9

[David Syzdek]

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

Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9

[Junio C Hamano]

"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)