From owner-freebsd-standards@FreeBSD.ORG Fri Apr 24 09:31:35 2015 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A693819 for ; Fri, 24 Apr 2015 09:31:35 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BF571F38 for ; Fri, 24 Apr 2015 09:31:33 +0000 (UTC) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.1/8.15.1) with ESMTPSA id t3O9VJeP084902 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 09:31:25 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: newlocale(3) appears to be broken? From: David Chisnall In-Reply-To: <20150423182733.GA14387@troutmask.apl.washington.edu> Date: Fri, 24 Apr 2015 10:31:14 +0100 Cc: freebsd-standards@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9239D309-A382-4691-B08E-739B545ED865@FreeBSD.org> References: <20150423182733.GA14387@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 09:31:35 -0000 On 23 Apr 2015, at 19:29, Steve Kargl = wrote: >=20 > It appears that newlocale(3) is broken. >=20 > First, the manpage indicates that one > needs to use >=20 > #include This is a typo in the man page, it should be xlocale.h >=20 > which leads to >=20 > troutmask:sgk[204] cc -o z r.c > r.c:1:10: fatal error: 'xlocale' file not found > #include > ^ > 1 error generated. >=20 > next the manpage says=20 >=20 > STANDARDS > This function conforms to IEEE Std 1003.1-2008 (``POSIX.1''). >=20 > However, http://pubs.opengroup.org/stage7tc1/functions/newlocale.html > says newlocale is declared in locale.h. =20 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. >=20 > Now consider >=20 > % cat r.c >=20 > #include >=20 > int > main(void) > { > locale_t a; > a =3D newlocale(0, "C", 0); > if (a) > return 0; > else > return 1; > } >=20 > troutmask:sgk[206] cc -o z -static r.c && ./z > Segmentation fault (core dumped) >=20 > 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=E2=80=99m a bit surprised = that this doesn=E2=80=99t happen in the dynamically linked version. = I=E2=80=99m testing a fix now. David