Bug 255646 - newlocale(LC_ALL_MASK, (locale_t) 0) wrongly destroys LC_COLLATE in an existing object
Summary: newlocale(LC_ALL_MASK, (locale_t) 0) wrongly destroys LC_COLLATE in an existi...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: Yuri Pankov
URL: https://reviews.freebsd.org/D30146
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-06 01:13 UTC by Karl Williamson
Modified: 2021-05-06 20:37 UTC (History)
1 user (show)

See Also:


Attachments
.c that illustrates the bug (969 bytes, text/plain)
2021-05-06 01:13 UTC, Karl Williamson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Williamson 2021-05-06 01:13:04 UTC
Created attachment 224718 [details]
.c that illustrates the bug

Compile and run the attached program.

The second newlocale() overwrites LC_COLLATE of the object created by the first newlocale(); the objects should be completely independent
Comment 1 Yuri Pankov freebsd_committer 2021-05-06 09:00:12 UTC
It's not really destroyed, rather this is a corner case for 3 locales - C, POSIX, C.UTF-8 - using the same static (as in "not loaded from file") collate object, and using newlocale() simply overwrites the name.
Comment 2 Karl Williamson 2021-05-06 20:37:49 UTC
I had considered the possibility that POSIX and C would have the same collating sequence.  But before I filed the report, I tried a third locale, which happened to be C.UTF-8.  I couldn't imagine that it would have the same collating sequence as the other two, and still don't.

\xC0\x80 is a legal sequence in the first two locales, but not in the third.  Are you ignoring input validity in collation?