{"thread":{"id":"28306","subject":"[PATCH 1/2] Add strtoimax() compatibility function.","startedAt":"2011-09-05T11:45:54Z","lastAt":"2011-09-06T11:17:39Z","messageCount":12,"participants":["Nix","Sverre Rabbelier","Junio C Hamano","Clemens Buchacher","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"174864","messageId":"1315223155-4218-1-git-send-email-nix@esperi.org.uk","threadId":"28306","inReplyTo":null,"subject":"[PATCH 1/2] Add strtoimax() compatibility function.","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2011-09-05T11:45:54Z","receivedAt":"2011-09-05T11:45:54Z","isPatch":true,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"Since systems that omit strtoumax() will likely omit strtomax() too,\nand likewise for strtoull() and strtoll(), we also adjust the\ncompatibility #defines from NO_STRTOUMAX to NO_STRTOMAX and from\nNO_STRTOULL to NO_STRTOLL, and have them cover both the signed and\nunsigned functions.\n\nSigned-off-by: Nick Alcock <nix@esperi.org.uk>\n---\n Makefile           |   36 ++++++++++++++++++------------------\n compat/strtoimax.c |   10 ++++++++++\n compat/strtoumax.c |    2 +-\n 3 files changed, 29 insertions(+), 19 deletions(-)\n create mode 100644 compat/strtoimax.c\n\ndiff --git a/Makefile b/Makefile\nindex 6bf7d6c..0959e07 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -57,9 +57,9 @@ all::\n #\n # Define NO_STRLCPY if you don't have strlcpy.\n #\n-# Define NO_STRTOUMAX if you don't have strtoumax in the C library.\n-# If your compiler also does not support long long or does not have\n-# strtoull, define NO_STRTOULL.\n+# Define NO_STRTOMAX if you don't have both strtoimax and strtoumax in the\n+# C library.  If your compiler also does not support long long or does\n+# not have strtoll or strtoull, define NO_STRTOLL.\n #\n # Define NO_SETENV if you don't have setenv in the C library.\n #\n@@ -804,7 +804,7 @@ ifeq ($(uname_S),OSF1)\n \t# Need this for u_short definitions et al\n \tBASIC_CFLAGS += -D_OSF_SOURCE\n \tSOCKLEN_T = int\n-\tNO_STRTOULL = YesPlease\n+\tNO_STRTOLL = YesPlease\n \tNO_NSEC = YesPlease\n endif\n ifeq ($(uname_S),Linux)\n@@ -890,7 +890,7 @@ ifeq ($(uname_S),SunOS)\n \t\tNO_UNSETENV = YesPlease\n \t\tNO_SETENV = YesPlease\n \t\tNO_STRLCPY = YesPlease\n-\t\tNO_STRTOUMAX = YesPlease\n+\t\tNO_STRTOMAX = YesPlease\n \t\tGIT_TEST_CMP = cmp\n \tendif\n \tifeq ($(uname_R),5.7)\n@@ -900,19 +900,19 @@ ifeq ($(uname_S),SunOS)\n \t\tNO_UNSETENV = YesPlease\n \t\tNO_SETENV = YesPlease\n \t\tNO_STRLCPY = YesPlease\n-\t\tNO_STRTOUMAX = YesPlease\n+\t\tNO_STRTOMAX = YesPlease\n \t\tGIT_TEST_CMP = cmp\n \tendif\n \tifeq ($(uname_R),5.8)\n \t\tNO_UNSETENV = YesPlease\n \t\tNO_SETENV = YesPlease\n-\t\tNO_STRTOUMAX = YesPlease\n+\t\tNO_STRTOMAX = YesPlease\n \t\tGIT_TEST_CMP = cmp\n \tendif\n \tifeq ($(uname_R),5.9)\n \t\tNO_UNSETENV = YesPlease\n \t\tNO_SETENV = YesPlease\n-\t\tNO_STRTOUMAX = YesPlease\n+\t\tNO_STRTOMAX = YesPlease\n \t\tGIT_TEST_CMP = cmp\n \tendif\n \tINSTALL = /usr/ucb/install\n@@ -954,7 +954,7 @@ ifeq ($(uname_S),FreeBSD)\n \tifeq ($(shell expr \"$(uname_R)\" : '4\\.'),2)\n \t\tPTHREAD_LIBS = -pthread\n \t\tNO_UINTMAX_T = YesPlease\n-\t\tNO_STRTOUMAX = YesPlease\n+\t\tNO_STRTOMAX = YesPlease\n \tendif\n \tPYTHON_PATH = /usr/local/bin/python\n \tHAVE_PATHS_H = YesPlease\n@@ -1092,8 +1092,8 @@ ifeq ($(uname_S),Windows)\n \tNO_MEMMEM = YesPlease\n \t# NEEDS_LIBICONV = YesPlease\n \tNO_ICONV = YesPlease\n-\tNO_STRTOUMAX = YesPlease\n-\tNO_STRTOULL = YesPlease\n+\tNO_STRTOMAX = YesPlease\n+\tNO_STRTOLL = YesPlease\n \tNO_MKDTEMP = YesPlease\n \tNO_MKSTEMPS = YesPlease\n \tSNPRINTF_RETURNS_BOGUS = YesPlease\n@@ -1139,7 +1139,7 @@ ifeq ($(uname_S),Interix)\n \tNO_IPV6 = YesPlease\n \tNO_MEMMEM = YesPlease\n \tNO_MKDTEMP = YesPlease\n-\tNO_STRTOUMAX = YesPlease\n+\tNO_STRTOMAX = YesPlease\n \tNO_NSEC = YesPlease\n \tNO_MKSTEMPS = YesPlease\n \tifeq ($(uname_R),3.5)\n@@ -1184,7 +1184,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))\n \tNO_MEMMEM = YesPlease\n \tNEEDS_LIBICONV = YesPlease\n \tOLD_ICONV = YesPlease\n-\tNO_STRTOUMAX = YesPlease\n+\tNO_STRTOMAX = YesPlease\n \tNO_MKDTEMP = YesPlease\n \tNO_MKSTEMPS = YesPlease\n \tNO_SVN_TESTS = YesPlease\n@@ -1440,12 +1440,12 @@ ifdef NO_STRLCPY\n \tCOMPAT_CFLAGS += -DNO_STRLCPY\n \tCOMPAT_OBJS += compat/strlcpy.o\n endif\n-ifdef NO_STRTOUMAX\n-\tCOMPAT_CFLAGS += -DNO_STRTOUMAX\n-\tCOMPAT_OBJS += compat/strtoumax.o\n+ifdef NO_STRTOMAX\n+\tCOMPAT_CFLAGS += -DNO_STRTOMAX\n+\tCOMPAT_OBJS += compat/strtoumax.o compat/strtoimax.o\n endif\n-ifdef NO_STRTOULL\n-\tCOMPAT_CFLAGS += -DNO_STRTOULL\n+ifdef NO_STRTOLL\n+\tCOMPAT_CFLAGS += -DNO_STRTOLL\n endif\n ifdef NO_STRTOK_R\n \tCOMPAT_CFLAGS += -DNO_STRTOK_R\ndiff --git a/compat/strtoimax.c b/compat/strtoimax.c\nnew file mode 100644\nindex 0000000..fca07a3\n--- /dev/null\n+++ b/compat/strtoimax.c\n@@ -0,0 +1,10 @@\n+#include \"../git-compat-util.h\"\n+\n+intmax_t gitstrtoimax (const char *nptr, char **endptr, int base)\n+{\n+#if defined(NO_STRTOLL)\n+\treturn strtol(nptr, endptr, base);\n+#else\n+\treturn strtoll(nptr, endptr, base);\n+#endif\n+}\ndiff --git a/compat/strtoumax.c b/compat/strtoumax.c\nindex 5541353..7feedfd 100644\n--- a/compat/strtoumax.c\n+++ b/compat/strtoumax.c\n@@ -2,7 +2,7 @@\n \n uintmax_t gitstrtoumax (const char *nptr, char **endptr, int base)\n {\n-#if defined(NO_STRTOULL)\n+#if defined(NO_STRTOLL)\n \treturn strtoul(nptr, endptr, base);\n #else\n \treturn strtoull(nptr, endptr, base);\n-- \n1.7.6.1.139.gcb612\n"},{"id":"174865","messageId":"1315223155-4218-2-git-send-email-nix@esperi.org.uk","threadId":"28306","inReplyTo":"1315223155-4218-1-git-send-email-nix@esperi.org.uk","subject":"[PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2011-09-05T11:45:55Z","receivedAt":"2011-09-05T11:45:55Z","isPatch":true,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"The config options core.packedGitWindowSize, core.packedGitLimit,\ncore.deltaBaseCacheLimit, core.bigFileThreshold, pack.windowMemory and\npack.packSizeLimit all claim to support suffixes up to and including\n'g'.  This implies that they should accept sizes >=2G on 64-bit\nsystems: certainly, specifying a size of 3g should not silently be\ntranslated to zero or transformed into a large negative value due to\ninteger overflow. However, due to use of git_config_int() rather than\ngit_config_ulong(), that is exactly what happens:\n\n% git config core.bigFileThreshold 2g\n% git gc --aggressive # with extra debugging code to print out\n                      # core.bigfilethreshold after parsing\nbigfilethreshold: -2147483648\n[...]\n\nThis is probably irrelevant for core.deltaBaseCacheLimit, but is\nproblematic for the other values. (It is particularly problematic for\ncore.packedGitLimit, which can't even be set to its default value in\nthe config file due to this bug.)\n\nThis fixes things for 32-bit platforms as well. They get the usual bad\nconfig error if an overlarge value is specified, e.g.:\n\nfatal: bad config value for 'core.bigfilethreshold' in /home/nix/.gitconfig\n\n32-bit platforms with no type larger than 'long' cannot detect this\ncase and will continue to silently misbehave, but the misbehaviour\nwill be somewhat different and more useful, since bigFileThreshold was\nalso being mistakenly treated as a signed value when it should have\nbeen unsigned.\n\nSigned-off-by: Nick Alcock <nix@esperi.org.uk>\n---\n config.c |   26 ++++++++++++++++----------\n 1 files changed, 16 insertions(+), 10 deletions(-)\n\ndiff --git a/config.c b/config.c\nindex 4183f80..b19df66 100644\n--- a/config.c\n+++ b/config.c\n@@ -333,7 +333,7 @@ static int git_parse_file(config_fn_t fn, void *data)\n \tdie(\"bad config file line %d in %s\", cf->linenr, cf->name);\n }\n \n-static int parse_unit_factor(const char *end, unsigned long *val)\n+static int parse_unit_factor(const char *end, uintmax_t *val)\n {\n \tif (!*end)\n \t\treturn 1;\n@@ -356,11 +356,14 @@ static int git_parse_long(const char *value, long *ret)\n {\n \tif (value && *value) {\n \t\tchar *end;\n-\t\tlong val = strtol(value, &end, 0);\n-\t\tunsigned long factor = 1;\n+\t\tintmax_t val = strtoimax(value, &end, 0);\n+\t\tuintmax_t factor = 1;\n \t\tif (!parse_unit_factor(end, &factor))\n \t\t\treturn 0;\n-\t\t*ret = val * factor;\n+\t\tval *= factor;\n+\t\tif (val > maximum_signed_value_of_type(long))\n+\t\t\treturn 0;\n+\t\t*ret = val;\n \t\treturn 1;\n \t}\n \treturn 0;\n@@ -370,9 +373,11 @@ int git_parse_ulong(const char *value, unsigned long *ret)\n {\n \tif (value && *value) {\n \t\tchar *end;\n-\t\tunsigned long val = strtoul(value, &end, 0);\n+\t\tuintmax_t val = strtoumax(value, &end, 0);\n \t\tif (!parse_unit_factor(end, &val))\n \t\t\treturn 0;\n+\t\tif (val > maximum_unsigned_value_of_type(long))\n+\t\t\treturn 0;\n \t\t*ret = val;\n \t\treturn 1;\n \t}\n@@ -391,6 +396,8 @@ int git_config_int(const char *name, const char *value)\n \tlong ret = 0;\n \tif (!git_parse_long(value, &ret))\n \t\tdie_bad_config(name);\n+\tif (ret > maximum_signed_value_of_type(int))\n+\t\tdie_bad_config(name);\n \treturn ret;\n }\n \n@@ -550,7 +557,7 @@ static int git_default_core_config(const char *var, const char *value)\n \n \tif (!strcmp(var, \"core.packedgitwindowsize\")) {\n \t\tint pgsz_x2 = getpagesize() * 2;\n-\t\tpacked_git_window_size = git_config_int(var, value);\n+\t\tpacked_git_window_size = git_config_ulong(var, value);\n \n \t\t/* This value must be multiple of (pagesize * 2) */\n \t\tpacked_git_window_size /= pgsz_x2;\n@@ -561,18 +568,17 @@ static int git_default_core_config(const char *var, const char *value)\n \t}\n \n \tif (!strcmp(var, \"core.bigfilethreshold\")) {\n-\t\tlong n = git_config_int(var, value);\n-\t\tbig_file_threshold = 0 < n ? n : 0;\n+\t\tbig_file_threshold = git_config_ulong(var, value);\n \t\treturn 0;\n \t}\n \n \tif (!strcmp(var, \"core.packedgitlimit\")) {\n-\t\tpacked_git_limit = git_config_int(var, value);\n+\t\tpacked_git_limit = git_config_ulong(var, value);\n \t\treturn 0;\n \t}\n \n \tif (!strcmp(var, \"core.deltabasecachelimit\")) {\n-\t\tdelta_base_cache_limit = git_config_int(var, value);\n+\t\tdelta_base_cache_limit = git_config_ulong(var, value);\n \t\treturn 0;\n \t}\n \n-- \n1.7.6.1.139.gcb612\n"},{"id":"174870","messageId":"CAGdFq_gFNHq9Cgv4F4Q6VQ=G7odfUJ5pUFWn=OYE-BfXzP=Enw@mail.gmail.com","threadId":"28306","inReplyTo":"1315223155-4218-2-git-send-email-nix@esperi.org.uk","subject":"Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-09-05T13:49:07Z","receivedAt":"2011-09-05T13:49:07Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Sep 5, 2011 at 13:45, Nix <nix@esperi.org.uk> wrote:\n> 32-bit platforms with no type larger than 'long' cannot detect this\n> case and will continue to silently misbehave, but the misbehaviour\n> will be somewhat different and more useful, since bigFileThreshold was\n> also being mistakenly treated as a signed value when it should have\n> been unsigned.\n\nIs it not possible to detect that the target value won't fit in the\nmax size of an int when parsing the config value?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"174871","messageId":"87ty8rm6th.fsf@spindle.srvr.nix","threadId":"28306","inReplyTo":"CAGdFq_gFNHq9Cgv4F4Q6VQ=G7odfUJ5pUFWn=OYE-BfXzP=Enw@mail.gmail.com","subject":"Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2011-09-05T13:56:10Z","receivedAt":"2011-09-05T13:56:10Z","isPatch":true,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 5 Sep 2011, Sverre Rabbelier said:\n\n> Heya,\n>\n> On Mon, Sep 5, 2011 at 13:45, Nix <nix@esperi.org.uk> wrote:\n>> 32-bit platforms with no type larger than 'long' cannot detect this\n>> case and will continue to silently misbehave, but the misbehaviour\n>> will be somewhat different and more useful, since bigFileThreshold was\n>> also being mistakenly treated as a signed value when it should have\n>> been unsigned.\n>\n> Is it not possible to detect that the target value won't fit in the\n> max size of an int when parsing the config value?\n\nWell, we're parsing longs, not ints. If sizeof(long)>sizeof(int), or we\nhave long long and sizeof(long long)>sizeof(int), then we can always\ndetect overflows when saving into the appropriate type: but if we don't\nhave long long, or if we have neither strto(u)ll() nor strto[ui]max(),\nwe could only detect overflow by looking at the raw text string and\nchecking it by hand to see if it would fit. I judged this pointless\nextra complexity for a very rare edge case (machines with neither\nstrot(u)ll() nor strto[ui]max() are generally quite old and people\naren't going to be specifying sizes in gigabytes on such machines\nanyway.)\n\n-- \nNULL && (void)\n"},{"id":"174896","messageId":"7v62l6b3bt.fsf@alter.siamese.dyndns.org","threadId":"28306","inReplyTo":"1315223155-4218-1-git-send-email-nix@esperi.org.uk","subject":"Re: [PATCH 1/2] Add strtoimax() compatibility function.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-06T06:19:18Z","receivedAt":"2011-09-06T06:19:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nix <nix@esperi.org.uk> writes:\n\n> Since systems that omit strtoumax() will likely omit strtomax() too,\n> and likewise for strtoull() and strtoll(), we also adjust the\n> compatibility #defines from NO_STRTOUMAX to NO_STRTOMAX and from\n> NO_STRTOULL to NO_STRTOLL, and have them cover both the signed and\n> unsigned functions.\n\nWhat would happen to people who know their systems lack strtoumax and have\nhappily using NO_STRTOUMAX in their config.mak already? Do their build\nsuddenly start breaking after this patch is applied and they all have to\nadjust to the new name?\n\nEven though \"no strtoumax() likely means no strtoimax()\" may be a good\nheuristics, I am not sure what we would gain by renaming these Makefile\nvariables. Can't you get the same effect by making existing NO_STRTOUMAX\nimply not having strtoimax(), and if you did so, wouldn't it be much less\nlikely that you would break existing people's build?\n"},{"id":"174901","messageId":"20110906074421.GB28490@ecki","threadId":"28306","inReplyTo":"87ty8rm6th.fsf@spindle.srvr.nix","subject":"Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2011-09-06T07:44:21Z","receivedAt":"2011-09-06T07:44:21Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Mon, Sep 05, 2011 at 02:56:10PM +0100, Nix wrote:\n> \n> Well, we're parsing longs, not ints. If sizeof(long)>sizeof(int), or we\n> have long long and sizeof(long long)>sizeof(int), then we can always\n> detect overflows when saving into the appropriate type: but if we don't\n> have long long, or if we have neither strto(u)ll() nor strto[ui]max(),\n> we could only detect overflow by looking at the raw text string and\n> checking it by hand to see if it would fit. I judged this pointless\n> extra complexity for a very rare edge case (machines with neither\n> strot(u)ll() nor strto[ui]max() are generally quite old and people\n> aren't going to be specifying sizes in gigabytes on such machines\n> anyway.)\n\nIs this also true for Windows and other platforms?\n\nAnd I don't think it's about whether or not people are likely to\nspecify sizes in gigabytes on old machines. People are bound to\nblindly copy configuration files from one machine to another. In\nany case, my expectation would be for the configuration options to\ndo what I tell them, or error out if they do not make sense.\n\nClemens\n"},{"id":"174905","messageId":"87ty8qjaof.fsf@spindle.srvr.nix","threadId":"28306","inReplyTo":"20110906074421.GB28490@ecki","subject":"Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2011-09-06T09:13:20Z","receivedAt":"2011-09-06T09:13:20Z","isPatch":true,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 6 Sep 2011, Clemens Buchacher uttered the following:\n\n> On Mon, Sep 05, 2011 at 02:56:10PM +0100, Nix wrote:\n>> \n>> Well, we're parsing longs, not ints. If sizeof(long)>sizeof(int), or we\n>> have long long and sizeof(long long)>sizeof(int), then we can always\n>> detect overflows when saving into the appropriate type: but if we don't\n>> have long long, or if we have neither strto(u)ll() nor strto[ui]max(),\n>> we could only detect overflow by looking at the raw text string and\n>> checking it by hand to see if it would fit. I judged this pointless\n>> extra complexity for a very rare edge case (machines with neither\n>> strot(u)ll() nor strto[ui]max() are generally quite old and people\n>> aren't going to be specifying sizes in gigabytes on such machines\n>> anyway.)\n>\n> Is this also true for Windows and other platforms?\n\nThere, uintmax_t is 'long long' and is longer than 'long', let alone\n'int', so this holds there too, or should.\n\n> And I don't think it's about whether or not people are likely to\n> specify sizes in gigabytes on old machines. People are bound to\n> blindly copy configuration files from one machine to another. In\n> any case, my expectation would be for the configuration options to\n> do what I tell them, or error out if they do not make sense.\n\nYeah, and we do that whenever practically possible: but fixing\nthis for the case that int/long is the largest available type\n(which among other things implies that we're not using GCC or\nany other C99 compiler or any of the myriad C89 compilers that\nimplmented 'long long') amounts to writing our own strtol()\nspecifically for this one case, to see if the parsed number is\ntoo long. And that is probably a maintenance burden too far.\n\nThe failure mode if you put a huge number in on such a platform is\nbetter than it used to be, too, especially for core.bigfilethreshold. We\nused to get a negative number that was latched to zero, which then\ndisabled compression entirely (I had an 83Mb pack turn itself into an\n837Mb one when that happened). Now we get a number that, while positive,\nis less positive than we expect, but still likely up in the hundreds of\nmillions.\n\n-- \nNULL && (void)\n"},{"id":"174906","messageId":"87pqjejamv.fsf@spindle.srvr.nix","threadId":"28306","inReplyTo":"7v62l6b3bt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/2] Add strtoimax() compatibility function.","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2011-09-06T09:14:16Z","receivedAt":"2011-09-06T09:14:16Z","isPatch":true,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 6 Sep 2011, Junio C. Hamano spake thusly:\n\n> Nix <nix@esperi.org.uk> writes:\n>\n>> Since systems that omit strtoumax() will likely omit strtomax() too,\n>> and likewise for strtoull() and strtoll(), we also adjust the\n>> compatibility #defines from NO_STRTOUMAX to NO_STRTOMAX and from\n>> NO_STRTOULL to NO_STRTOLL, and have them cover both the signed and\n>> unsigned functions.\n>\n> What would happen to people who know their systems lack strtoumax and have\n> happily using NO_STRTOUMAX in their config.mak already? Do their build\n> suddenly start breaking after this patch is applied and they all have to\n> adjust to the new name?\n\nUh. Yeah. Oops.\n\n> Even though \"no strtoumax() likely means no strtoimax()\" may be a good\n> heuristics, I am not sure what we would gain by renaming these Makefile\n> variables. Can't you get the same effect by making existing NO_STRTOUMAX\n> imply not having strtoimax(), and if you did so, wouldn't it be much less\n> likely that you would break existing people's build?\n\nYes, but I thought that might be too confusing (and having four\nvariables for this one case seemed ridiculous). I'm happy to rename it\nback.\n\n-- \nNULL && (void)\n"},{"id":"174910","messageId":"4E65F451.4070900@viscovery.net","threadId":"28306","inReplyTo":"87ty8qjaof.fsf@spindle.srvr.nix","subject":"Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-09-06T10:22:09Z","receivedAt":"2011-09-06T10:22:09Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 9/6/2011 11:13, schrieb Nix:\n> ... amounts to writing our own strtol()\n> specifically for this one case, to see if the parsed number is\n> too long.\n\nWhy so? strtol() can report overflow:\n\nRETURN VALUE\n\n    ...\n    If the correct value is outside the range of representable values,\n{LONG_MIN}, {LONG_MAX}, {LLONG_MIN}, or {LLONG_MAX} shall be returned\n(according to the sign of the value), and errno set to [ERANGE].\n\n-- Hannes\n"},{"id":"174917","messageId":"87liu2j7c3.fsf@spindle.srvr.nix","threadId":"28306","inReplyTo":"4E65F451.4070900@viscovery.net","subject":"Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2011-09-06T10:25:32Z","receivedAt":"2011-09-06T10:25:32Z","isPatch":true,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 6 Sep 2011, Johannes Sixt verbalised:\n\n> Why so? strtol() can report overflow:\n\n... it can?!\n\n>     ...\n>     If the correct value is outside the range of representable values,\n> {LONG_MIN}, {LONG_MAX}, {LLONG_MIN}, or {LLONG_MAX} shall be returned\n> (according to the sign of the value), and errno set to [ERANGE].\n\nI've been using it for longer than I care to imagine and I've never once\nnoticed that.\n\nOK, I'll add range checking support then! following which we can detect\nconfig value overflow on the most pathetic platform imaginable, except\nthat such a platform would probably not bother to set ERANGE properly ;}\n\nFixed patch following later today ripping out the STRTOMAX renaming and\nadding proper range checking.\n\n-- \nNULL && (void)\n"},{"id":"174918","messageId":"4E65F842.7080601@viscovery.net","threadId":"28306","inReplyTo":"87liu2j7c3.fsf@spindle.srvr.nix","subject":"Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-09-06T10:38:58Z","receivedAt":"2011-09-06T10:38:58Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 9/6/2011 12:25, schrieb Nix:\n> OK, I'll add range checking support then!\n\nDon't forget to follow this advice noted on the POSIX page\n(http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html):\n\nSince 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are\nreturned on error and are also valid returns on success, an application\nwishing to check for error situations should set errno to 0, then call\nstrtol() or strtoll(), then check errno.\n\n-- Hannes\n"},{"id":"174920","messageId":"87ehztkjho.fsf@spindle.srvr.nix","threadId":"28306","inReplyTo":"4E65F842.7080601@viscovery.net","subject":"Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2011-09-06T11:17:39Z","receivedAt":"2011-09-06T11:17:39Z","isPatch":true,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 6 Sep 2011, Johannes Sixt stated:\n\n> Am 9/6/2011 12:25, schrieb Nix:\n>> OK, I'll add range checking support then!\n>\n> Don't forget to follow this advice noted on the POSIX page\n> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html):\n>\n> Since 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are\n> returned on error and are also valid returns on success, an application\n> wishing to check for error situations should set errno to 0, then call\n> strtol() or strtoll(), then check errno.\n\nOh, I've fallen into *that* trap before with math functions setting\nERANGE/EDOM. Thanks for the reminder :)\n\n-- \nNULL && (void)\n"}]}