Jeroen Ruigrok van der Werven <asmo...@in-nomine.org> added the comment:
I asked that as well on the POSIX/SUS list and Don Cragun responded with: "If you make the last argument to setlocale() be a pointer to unallocated memory, implementations would be allowed to set errno to EFAULT and terminate the process with a core dump even when this section says "No errors are defined." An implementation could also set errno to ENOENT (e.g., if the "B" locale wasn't known) or to EINVAL (e.g., if the "B" locale existed but the LC_CTYPE portion of the locale was not in the proper format). That wording just means that the standard doesn't require implementations to detect errors like these nor to report specific error values for different possible errors." On the subject whether or not returning a null pointer should be considered he said: "The standard is silent on this issue. Why does it make any difference to an application? If setlocale(LC_CTYPE, "B") returns a null pointer, the LC_CTYPE portion of the locale was not changed. If setlocale(LC_CTYPE, "B") does not return a null pointer, the LC_CTYPE portion of the locale was successfully changed." I am just wondering why we want to be quite different from how many other languages are approaching the issue. Sure enough, we can use a try: construct, but it kind of defeats the principle of least astonishment by being different from the rest on this issue. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1443504> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
