From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#24186: setlocale can't be localised Date: Mon, 8 Aug 2016 17:32:14 +0100 Message-ID: <20160808163214.GF24721@fysh.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1470674627 20645 195.159.176.226 (8 Aug 2016 16:43:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2016 16:43:47 +0000 (UTC) To: 24186@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Aug 08 18:43:39 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bWneC-000338-F2 for guile-bugs@m.gmane.org; Mon, 08 Aug 2016 18:43:28 +0200 Original-Received: from localhost ([::1]:58680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWne9-0003mC-DG for guile-bugs@m.gmane.org; Mon, 08 Aug 2016 12:43:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWnUC-0002Ge-Ak for bug-guile@gnu.org; Mon, 08 Aug 2016 12:33:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWnU6-00086a-8e for bug-guile@gnu.org; Mon, 08 Aug 2016 12:33:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWnU6-00086W-5m for bug-guile@gnu.org; Mon, 08 Aug 2016 12:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bWnU6-0000Bn-17 for bug-guile@gnu.org; Mon, 08 Aug 2016 12:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 08 Aug 2016 16:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 24186 X-GNU-PR-Package: guile X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.1470673959697 (code B ref -1); Mon, 08 Aug 2016 16:33:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 8 Aug 2016 16:32:39 +0000 Original-Received: from localhost ([127.0.0.1]:60262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bWnTj-0000BA-Bu for submit@debbugs.gnu.org; Mon, 08 Aug 2016 12:32:39 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bWnTh-0000Ay-IA for submit@debbugs.gnu.org; Mon, 08 Aug 2016 12:32:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWnTb-00080n-4S for submit@debbugs.gnu.org; Mon, 08 Aug 2016 12:32:32 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:40577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWnTb-00080O-1h for submit@debbugs.gnu.org; Mon, 08 Aug 2016 12:32:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWnTY-0001fc-KR for bug-guile@gnu.org; Mon, 08 Aug 2016 12:32:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWnTS-0007yt-JX for bug-guile@gnu.org; Mon, 08 Aug 2016 12:32:27 -0400 Original-Received: from river.fysh.org ([87.98.248.19]:48290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWnTS-0007xa-De for bug-guile@gnu.org; Mon, 08 Aug 2016 12:32:22 -0400 Original-Received: from zefram by river.fysh.org with local (Exim 4.84_2 #1 (Debian)) id 1bWnTK-0007yZ-Ld; Mon, 08 Aug 2016 17:32:14 +0100 Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8361 Archived-At: In Guile 1.8 it was possible to localise the effect of a setlocale operation, but in Guile 2.0 it's no longer possible by natural use of the locale API. This loss of a useful facility is either a bug or something that needs to be discussed in the documentation. In Guile 1.8 one could perform a temporary setlocale for the execution of some piece of code, and revert its effect by another setlocale on unwind. This looks like: (define (call-with-locale cat newval body) (let ((oldval #f)) (dynamic-wind (lambda () (set! oldval (setlocale cat)) (setlocale cat newval)) body (lambda () (setlocale cat oldval))))) Some difficulty arises from this being temporally scoped, where dynamic or lexical scoping would be nicer, but in single-threaded programs it works pretty well. The C setlocale(3) API, after which Guile's setlocale is modelled, is obviously designed to enable this kind of mechanism: the read operation reports all relevant state, and the write operation with the old value sets it all back as it was. It is critical to this ability that the read operation does indeed report all the state that will be set. In Guile 2.0, the setlocale function no longer corresponds so closely to the C setlocale(3), and this critical guarantee has been lost. I have previously reported in bug#22910 that the setlocale read operation has a side effect on port encoding, and obviously that interferes with the above code, but actually there's still a problem if that's fixed. The setlocale *write* operation also affects port encoding (actually the default port encoding fluid and the encoding of currently-selected ports), and that seems to be an intentional change, but it also breaks the above code. The setlocale read operation doesn't report the encoding of the currently-selected ports, so doesn't represent everything that setlocale will set. The setlocale write operation is not even capable of setting the port encodings independently: it sets all three to the encoding nominated by the locale selected for LC_CTYPE purposes. I think adding this extra effect to setlocale was a mistake. It doesn't fit the locale API. If the extra effect is removed, that would resolve this problem. If you really want setlocale to have this effect, then something needs to be done to address the ability that has been lost. The documentation certainly needs to describe the effect on port encoding, which it currently doesn't. (There is a mention of some interaction with the %default-port-encoding fluid in the documentation of that fluid, but it doesn't match reality: it doesn't say that setlocale writes to the fluid.) It also ought to specifically warn that the setlocale save-and-restore dance that works in C doesn't work here. It should explain what needs to be done by library functions that want to achieve a localised locale change. Are they entirely forbidden to use setlocale? Are they expected to manually save and restore port encodings around setlocale calls? (This is complicated by set-port-encoding! not accepting #f as an encoding value, despite it actually being a permitted value for the encoding slot.) Some example code equivalent to the above call-with-locale would be useful. -zefram