Date: Fri, 24 Apr 2015 10:31:14 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-standards@freebsd.org Subject: Re: newlocale(3) appears to be broken? Message-ID: <9239D309-A382-4691-B08E-739B545ED865@FreeBSD.org> In-Reply-To: <20150423182733.GA14387@troutmask.apl.washington.edu>
index | next in thread | previous in thread | raw e-mail
On 23 Apr 2015, at 19:29, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: > > It appears that newlocale(3) is broken. > > First, the manpage indicates that one > needs to use > > #include <xlocale> This is a typo in the man page, it should be xlocale.h > > which leads to > > troutmask:sgk[204] cc -o z r.c > r.c:1:10: fatal error: 'xlocale' file not found > #include <xlocale> > ^ > 1 error generated. > > next the manpage says > > STANDARDS > This function conforms to IEEE Std 1003.1-2008 (``POSIX.1''). > > However, http://pubs.opengroup.org/stage7tc1/functions/newlocale.html > says newlocale is declared in locale.h. If you have the correct preprocessor definitions to indicate a POSIX2008 target, then they are visible in locale.h. For earlier POSIX targets, they are exposed unconditionally in xlocale.h. This is for Darwin (and, I think, GNU) compatibility. I think that we should probably change the man pages to only refer to locale.h. > > Now consider > > % cat r.c > > #include <locale.h> > > int > main(void) > { > locale_t a; > a = newlocale(0, "C", 0); > if (a) > return 0; > else > return 1; > } > > troutmask:sgk[206] cc -o z -static r.c && ./z > Segmentation fault (core dumped) > > troutmask:sgk[206] cc -o z -static r.c && ./z > Segmentation fault (core dumped) > troutmask:sgk[207] gdb782 z z.core > [New process 100313] > Core was generated by `z'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x0000000000415798 in newlocale () > (gdb) bt > #0 0x0000000000415798 in newlocale () > #1 0x0000000000400434 in main () I can reproduce this, though only with static linking. Omitting the -static results in the program working correctly. It appears to be caused by __xlocale_C_ctype being declared const, so the reference count manipulation causes segmentation faults. I’m a bit surprised that this doesn’t happen in the dynamically linked version. I’m testing a fix now. Davidhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9239D309-A382-4691-B08E-739B545ED865>