Re: lib/60219: sysconf overpromises TZNAME_MAX

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/60219; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/60219: sysconf overpromises TZNAME_MAX
Date: Fri, 01 May 2026 12:19:08 +0700

     Date:        Thu, 30 Apr 2026 19:35:00 +0000 (UTC)
     From:        "wiz%NetBSD.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20260430193500.7870C1A9241%mollari.NetBSD.org@localhost>
 
 
   | Bruno Haible investigated and found that even though sysconf(3) returns
   | 511 for sysconf (_SC_TZNAME_MAX), which is also what I see on my system:
   |
   | # getconf TZNAME_MAX
   | 511
   |
   | libc seems to have a limit of 254 instead.
 
 Yes, that is clearly broken, sysconf(_SC_TZNAME_MAX) is supposed to
 return the minimum value that TZNAME_MAX can be - the POSIX default for that
 is 6 (which is perhaps a bit short, but these are the abbreviations
 ("EST" etc) and don't need to be all that long).    The current tzcode
 max length is 254 (way more than 6) - chosen so the length of the abbrev
 will fit in one byte.
 
 Returning NAME_MAX (which has nothing whatever to do with the issue)
 which is what we were doing is nonsense, it is more than libc (and hence
 zic) allows, when it is supposed to be less (or equal).   It is almost
 as if the proverbial someone believed that TZNAME_MAX has something to
 do with the file name (America/New_York) - for which NAME_MAX might be
 appropriate.
 
 There are two possible solutions, one is to treat sysconf(_SC_TZNAME_MAX)
 as it is defined, and make it the min value we'd ever support (say 31 or
 something like that) even though we actually support lots more than that
 (254), or we set it to be the value we actually support, rather than being
 the minimum allowed value.
 
 In some ways I prefer the former, it means the value will never need to
 change in the future (unless something very weird happens), whereas setting
 it to the actual supported value means every new tzcode release might alter
 what it gets set to (tzcode changed it from 255 to 254 not all that long
 ago, so the (unsigned)"-1" byte value could be used for other purposes).
 
 For now I am going to do the latter however, as that seems more consistent
 with how we typically set these "minimum allowed" sysconf values - making
 them represent what we currently allow, which is clearly both the minimum
 max value, and the max max value (for now).
 
   | I'm not sure where the 511 for _SC_TZNAME_MAX comes from;
 
 libc/gen/sysctl.c - the user.whatever sysctl() values are all embedded
 in there.   (sysconf() uses sysctl() to get the value - no actual system
 call is required for it).
 
   | where I think 'types' should be replaced by 'characters'.
 
 That typo exists in several places, I found several, but no idea if
 I got all that exist.
 
 kre