"Carlos O'Donell" <car...@redhat.com> skribis: > Despite Roland saying "LGTM", I think this is not a good change. > > Firstly, it's not the community consensus as Ondrej is pointing out. > > https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling
“Assertions are for internal consistency checking only.” I would argue that what this patch changes is not an internal consistency check. Furthermore, the function in question returns EINVAL in other similar cases–e.g., when libc 2.22 loads LC_COLLATE data from libc 2.21. So it is not clear to me that the patch would be a violation of these rules. WDYT? > It is a fundamental system misconfiguration issue not to have upgraded > the binary locale data from one release to another. I would not call it “misconfiguration.” With GNU Guix, unprivileged users can install packages in their “profile” and they are free to choose whether and when to upgrade those packages. Consequently, they might be using a libc version different from the one the system administrator used to build the system-wide locale data. Currently, the assertion failure greatly penalizes this use case: https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00717.html Returning EINVAL instead of aborting would make things easier. But it’s not perfect. IMO, a discussion on improving the coexistence of different libc/locale versions on the same system is in order. But it’s beyond the scope of this two-line patch. Thanks, Ludo’.