Hi Ted and Karl, Ted Unangst wrote on Fri, Mar 29, 2019 at 12:34:20AM -0400: > Karl Williamson wrote: >> On 3/28/19 8:03 AM, Ingo Schwarze wrote:
>>> It is unspecified whether the locale object pointed to by base >>> shall be modified, or freed and a new locale object created. >> I can see how you might be able to argue for your interpretation. >> I believe the wording in the spec is poor in this case (and it >> isn't the only such place). Deplorably so. >> I, and every other implementer takes the above text >> to mean, that it's up to the implementation as to how to combine 'base' >> with the new locale specified by the other parameters. 'base' can be >> modified and returned, or 'base' can be freed with some new locale which >> is the combination of 'base' and the other parameters. I don't take >> that wording to mean that 'base' can be irrelevant. That can't be the >> intent, as that would mean wildly unportable code, and no way for the >> program to specify an update to a category in isolation from the others. > I would agree. Fair enough, you convinced me that, if my interpretation of the standard is valid, then parts of the specification of newlocale(3) aren't useful. So i now agree it's probably a bug in the standard, and i filed http://austingroupbugs.net/view.php?id=1243 >>> In any case, in the commit message, do not call it a "bug fix", >>> describe it as a change for compatibility with other systems. >>> >>> Ted, feel free to either commit this version or tell me to commit. > Your version is good to commit. Committed, thanks for analyzing and reporting the issue and for drafting and checking diffs. > If you like, you may call it a workaround for a > specification bug that permitted the current behavior. :) While that would sound witty and humorous commit messages can be fun, they can also provoke misunderstandings, so i opted for a neutral wording of the commit message instead, see below. Yours, Ingo CVSROOT: /cvs Module name: src Changes by: schwa...@cvs.openbsd.org 2019/03/29 06:34:44 Modified files: lib/libc/locale: newlocale.3 newlocale.c Log message: Copy categories outside "mask" from "oldloc" to the new locale object. While POSIX appears to allow the old behaviour of ignoring "oldloc", Ted and Karl convinced me that is a bug in the spec and the Austin group almost certainly intended to require the new behaviour. Anyway, compatibility strongly suggests the new behaviour because most (or maybe even all?) other systems do not ignore "oldloc", and some software appears to depend on the copying from "oldloc" to the new locale. Issue analyzed and reported by Karl Williamson <public at khwilliamson dot com> with support from the Perl 5 community. This final diff is similar to two earlier diffs from Ted, but handles invalid input in a mode robust way. OK tedu@.
