{"thread":{"id":"16048","subject":"[PATCH] Add support for uintmax_t type on FreeBSD 4.9","startedAt":"2008-10-26T11:52:37Z","lastAt":"2008-10-28T04:14:24Z","messageCount":6,"participants":["David M. Syzdek","Junio C Hamano","David Syzdek"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"93974","messageId":"1225021957-11880-1-git-send-email-david.syzdek@acsalaska.net","threadId":"16048","inReplyTo":null,"subject":"[PATCH] Add support for uintmax_t type on FreeBSD 4.9","fromName":"David M. Syzdek","fromEmail":"david.syzdek@acsalaska.net","sentAt":"2008-10-26T11:52:37Z","receivedAt":"2008-10-26T11:52:37Z","isPatch":true,"sender":{"key":"david.syzdek@acsalaska.net","avatar":"https://gravatar.com/avatar/e95b1d3f9cd971d72dc364b7d942090876dd515c89a3252bd2baa8702a437f38?d=mp&s=160"},"body":"This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then\nuintmax_t is defined as uint32_t. This adds a test to configure.ac for\nuintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY.\n\nSigned-off-by: David M. Syzdek <david.syzdek@acsalaska.net>\n---\n Makefile      |    3 +++\n config.mak.in |    1 +\n configure.ac  |    8 ++++++++\n 3 files changed, 12 insertions(+), 0 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 0d40f0e..bf6a6dc 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -931,6 +931,9 @@ endif\n ifdef NO_IPV6\n \tBASIC_CFLAGS += -DNO_IPV6\n endif\n+ifdef NO_UINTMAX_T\n+\tBASIC_CFLAGS += -Duintmax_t=uint32_t\n+endif\n ifdef NO_SOCKADDR_STORAGE\n ifdef NO_IPV6\n \tBASIC_CFLAGS += -Dsockaddr_storage=sockaddr_in\ndiff --git a/config.mak.in b/config.mak.in\nindex b776149..c6558eb 100644\n--- a/config.mak.in\n+++ b/config.mak.in\n@@ -39,6 +39,7 @@ NO_C99_FORMAT=@NO_C99_FORMAT@\n NO_STRCASESTR=@NO_STRCASESTR@\n NO_MEMMEM=@NO_MEMMEM@\n NO_STRLCPY=@NO_STRLCPY@\n+NO_UINTMAX_T=@NO_UINTMAX_T@\n NO_STRTOUMAX=@NO_STRTOUMAX@\n NO_SETENV=@NO_SETENV@\n NO_UNSETENV=@NO_UNSETENV@\ndiff --git a/configure.ac b/configure.ac\nindex d3b8bc3..d9de93f 100644\n--- a/configure.ac\n+++ b/configure.ac\n@@ -415,6 +415,14 @@ AC_CHECK_FUNC(strlcpy,[\n [NO_STRLCPY=YesPlease])\n AC_SUBST(NO_STRLCPY)\n #\n+# Define NO_UINTMAX_T if your platform does not have uintmax_t\n+AC_CHECK_TYPE(uintmax_t,\n+[NO_UINTMAX_T=],\n+[NO_UINTMAX_T=YesPlease],[\n+#include <inttypes.h>\n+])\n+AC_SUBST(NO_UINTMAX_T)\n+#\n # Define NO_STRTOUMAX if you don't have strtoumax in the C library.\n AC_CHECK_FUNC(strtoumax,[\n  AC_SEARCH_LIBS(strtoumax,,\n-- \n1.6.0.2.GIT\n"},{"id":"94019","messageId":"7vy70aip06.fsf@gitster.siamese.dyndns.org","threadId":"16048","inReplyTo":"1225021957-11880-1-git-send-email-david.syzdek@acsalaska.net","subject":"Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-27T05:30:17Z","receivedAt":"2008-10-27T05:30:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David M. Syzdek\" <david.syzdek@acsalaska.net> writes:\n\n> This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then\n> uintmax_t is defined as uint32_t. This adds a test to configure.ac for\n> uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY.\n> ...\n> diff --git a/Makefile b/Makefile\n> index 0d40f0e..bf6a6dc 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -931,6 +931,9 @@ endif\n>  ifdef NO_IPV6\n>  \tBASIC_CFLAGS += -DNO_IPV6\n>  endif\n> +ifdef NO_UINTMAX_T\n> +\tBASIC_CFLAGS += -Duintmax_t=uint32_t\n> +endif\n\nI have a stupid question.\n\nWould it be a more appropriate improvement to do it like this:\n\n\tifdef USE_THIS_AS_UINTMAX_T\n            BASIC_CFLAGS += -Duintmax_t=\"$(USE_THIS_AS_UINTMAX_T)\"\n        endif\n\nand then add a section for FreeBSD 4.9-SECURITY like this:\n\n\tifeq ($(uname_R),4.9-SECURITY)\n        \tUSE_THIS_AS_UINTMAX_T = uint32_t\n\tendif\n\nThat way, an oddball 64-bit machine can use uint64_t here if it wants to,\npossibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).\n"},{"id":"94023","messageId":"9a0027270810262246i56cf5515l5fa0875f91d90a7a@mail.gmail.com","threadId":"16048","inReplyTo":"9a0027270810262239r311074m51d382bdd95fd0dc@mail.gmail.com","subject":"Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9","fromName":"David Syzdek","fromEmail":"syzdek@gmail.com","sentAt":"2008-10-27T05:46:20Z","receivedAt":"2008-10-27T05:46:20Z","isPatch":true,"sender":{"key":"syzdek@gmail.com","avatar":"https://gravatar.com/avatar/7f7b4df7a7d9be0b968c23c9fb9281953356e59ddb5d6dd8f02a6ddf3d9d9d22?d=mp&s=160"},"body":"On Sun, Oct 26, 2008 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> \"David M. Syzdek\" <david.syzdek@acsalaska.net> writes:\n>\n> > This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then\n> > uintmax_t is defined as uint32_t. This adds a test to configure.ac for\n> > uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY.\n> > ...\n> > diff --git a/Makefile b/Makefile\n> > index 0d40f0e..bf6a6dc 100644\n> > --- a/Makefile\n> > +++ b/Makefile\n> > @@ -931,6 +931,9 @@ endif\n> >  ifdef NO_IPV6\n> >       BASIC_CFLAGS += -DNO_IPV6\n> >  endif\n> > +ifdef NO_UINTMAX_T\n> > +     BASIC_CFLAGS += -Duintmax_t=uint32_t\n> > +endif\n>\n> I have a stupid question.\n>\n> Would it be a more appropriate improvement to do it like this:\n>\n>        ifdef USE_THIS_AS_UINTMAX_T\n>            BASIC_CFLAGS += -Duintmax_t=\"$(USE_THIS_AS_UINTMAX_T)\"\n>        endif\n>\n> and then add a section for FreeBSD 4.9-SECURITY like this:\n>\n>        ifeq ($(uname_R),4.9-SECURITY)\n>                USE_THIS_AS_UINTMAX_T = uint32_t\n>        endif\n>\n> That way, an oddball 64-bit machine can use uint64_t here if it wants to,\n> possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).\n>\n\nYour suggestion provides more flexibility for other environments. I\nwas making the assumption that 64-bit systems would define uintmax_t,\nhowever in retrospect that would be unwise.\nWould you like me to resubmit the patches with your modifications?\n\n\n--\nAn earthquake wiped out Etchisketchistan today.\n  -- Onion TV\n"},{"id":"94024","messageId":"7v1vy2imt2.fsf@gitster.siamese.dyndns.org","threadId":"16048","inReplyTo":"9a0027270810262246i56cf5515l5fa0875f91d90a7a@mail.gmail.com","subject":"Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-27T06:17:45Z","receivedAt":"2008-10-27T06:17:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David Syzdek\" <syzdek@gmail.com> writes:\n\n> On Sun, Oct 26, 2008 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n>> I have a stupid question.\n>>\n>> Would it be a more appropriate improvement to do it like this:\n>>\n>>        ifdef USE_THIS_AS_UINTMAX_T\n>>            BASIC_CFLAGS += -Duintmax_t=\"$(USE_THIS_AS_UINTMAX_T)\"\n>>        endif\n>>\n>> and then add a section for FreeBSD 4.9-SECURITY like this:\n>>\n>>        ifeq ($(uname_R),4.9-SECURITY)\n>>                USE_THIS_AS_UINTMAX_T = uint32_t\n>>        endif\n>>\n>> That way, an oddball 64-bit machine can use uint64_t here if it wants to,\n>> possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).\n>>\n>\n> Your suggestion provides more flexibility for other environments. I\n> was making the assumption that 64-bit systems would define uintmax_t,\n> however in retrospect that would be unwise.\n> Would you like me to resubmit the patches with your modifications?\n\nActually there was a reason why I said this was a \"stupid\" question.  I\nthink your assumption on 64-bit platforms would hold in practice, and my\nsuggestion could be an unnecessary overengineering.  If nobody knows of a\nsystem that would benefit from such a generalization, your original patch\nwould be better, partly because I think:\n\n (1) USE_THIS_AS_UINTMAX_T is just for demonstration of concept and is a\n     terrible name we cannot possibly use in our Makefile.  We have to\n     spend brain cycles to come up with a better name; and\n\n (2) It may be tricky to come up with autoconf macros to determine what to\n     set USE_THIS_AS_UINTMAX_T to.\n\nAs a slightly unrelated aside, I find it somewhat unfortunate that the\nconditional says \"4.9-SECURITY\", which is a bit too explicit and specific.\nto my taste.  I do not know how FreeBSD versioning scheme works, but\nwouldn't your change work equally well for 4.9-RELEASE or 4.11-RELEASE?\n\nI suspect that you would want to say \"$(uname_R) that begins with '4.' or\nsmaller needs this workaround\", as strtoul(3) manual page seems to appear\nfirst in FreeBSD 5.0-RELEASE (but not found in FreeBSD 4.11-RELEASE).\n"},{"id":"94046","messageId":"9a0027270810270623h4c0c34d0vcd92f61edff6da5@mail.gmail.com","threadId":"16048","inReplyTo":"7v1vy2imt2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9","fromName":"David Syzdek","fromEmail":"syzdek@gmail.com","sentAt":"2008-10-27T13:23:15Z","receivedAt":"2008-10-27T13:23:15Z","isPatch":true,"sender":{"key":"syzdek@gmail.com","avatar":"https://gravatar.com/avatar/7f7b4df7a7d9be0b968c23c9fb9281953356e59ddb5d6dd8f02a6ddf3d9d9d22?d=mp&s=160"},"body":"On Sun, Oct 26, 2008 at 10:17 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> \"David Syzdek\" <syzdek@gmail.com> writes:\n>\n>> On Sun, Oct 26, 2008 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> ...\n>>> I have a stupid question.\n>>>\n>>> Would it be a more appropriate improvement to do it like this:\n>>>\n>>>        ifdef USE_THIS_AS_UINTMAX_T\n>>>            BASIC_CFLAGS += -Duintmax_t=\"$(USE_THIS_AS_UINTMAX_T)\"\n>>>        endif\n>>>\n>>> and then add a section for FreeBSD 4.9-SECURITY like this:\n>>>\n>>>        ifeq ($(uname_R),4.9-SECURITY)\n>>>                USE_THIS_AS_UINTMAX_T = uint32_t\n>>>        endif\n>>>\n>>> That way, an oddball 64-bit machine can use uint64_t here if it wants to,\n>>> possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).\n>>>\n>>\n>> Your suggestion provides more flexibility for other environments. I\n>> was making the assumption that 64-bit systems would define uintmax_t,\n>> however in retrospect that would be unwise.\n>> Would you like me to resubmit the patches with your modifications?\n>\n> Actually there was a reason why I said this was a \"stupid\" question.  I\n> think your assumption on 64-bit platforms would hold in practice, and my\n> suggestion could be an unnecessary overengineering.  If nobody knows of a\n> system that would benefit from such a generalization, your original patch\n> would be better, partly because I think:\n>\n>  (1) USE_THIS_AS_UINTMAX_T is just for demonstration of concept and is a\n>     terrible name we cannot possibly use in our Makefile.  We have to\n>     spend brain cycles to come up with a better name; and\n>\n>  (2) It may be tricky to come up with autoconf macros to determine what to\n>     set USE_THIS_AS_UINTMAX_T to.\n>\n> As a slightly unrelated aside, I find it somewhat unfortunate that the\n> conditional says \"4.9-SECURITY\", which is a bit too explicit and specific.\n> to my taste.  I do not know how FreeBSD versioning scheme works, but\n> wouldn't your change work equally well for 4.9-RELEASE or 4.11-RELEASE?\n>\n> I suspect that you would want to say \"$(uname_R) that begins with '4.' or\n> smaller needs this workaround\", as strtoul(3) manual page seems to appear\n> first in FreeBSD 5.0-RELEASE (but not found in FreeBSD 4.11-RELEASE).\n>\n\nThe following should match against FreeBSD 4.x:\n\n\tFREEBSD_MAJOR := $(shell sh -c 'echo $(uname_R) |cut -d. -f1')\n\tifeq ($(FREEBSD_MAJOR),4)\n\t\tNO_UINTMAX_T = YesPlease\n\t\tNO_STRTOUMAX = YesPlease\n\tendif\n\nIs the use of FREEBSD_MAJOR okay, or would another name be more appropriate?\n\n\n\n-- \nAn earthquake wiped out Etchisketchistan today.\n   -- Onion TV\n"},{"id":"94091","messageId":"7v8ws9gxun.fsf@gitster.siamese.dyndns.org","threadId":"16048","inReplyTo":"9a0027270810270623h4c0c34d0vcd92f61edff6da5@mail.gmail.com","subject":"Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-28T04:14:24Z","receivedAt":"2008-10-28T04:14:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David Syzdek\" <syzdek@gmail.com> writes:\n\n> The following should match against FreeBSD 4.x:\n>\n> \tFREEBSD_MAJOR := $(shell sh -c 'echo $(uname_R) |cut -d. -f1')\n> \tifeq ($(FREEBSD_MAJOR),4)\n> \t\tNO_UINTMAX_T = YesPlease\n> \t\tNO_STRTOUMAX = YesPlease\n> \tendif\n>\n> Is the use of FREEBSD_MAJOR okay, or would another name be more appropriate?\n\nOther parts of the Makefile seems to do something like this:\n\n\tifeq ($(shell expr \"$(uname_R)\" : '4\\.'),2)\n        \n"}]}