From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Avoid malloc/free/dynwind for POSIX subrs that take strings Date: Mon, 18 May 2020 08:50:15 +0200 Message-ID: <87ftbxwxco.fsf@igalia.com> References: <87h7x2qbxa.fsf@inria.fr> <87a72m26bv.fsf@igalia.com> <871rninskn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="62065"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: guile-devel@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon May 18 08:56:34 2020 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jaZhR-000G16-RT for guile-devel@m.gmane-mx.org; Mon, 18 May 2020 08:56:33 +0200 Original-Received: from localhost ([::1]:43836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaZhQ-0004Jf-To for guile-devel@m.gmane-mx.org; Mon, 18 May 2020 02:56:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33756) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaZby-0002BY-2G for guile-devel@gnu.org; Mon, 18 May 2020 02:50:54 -0400 Original-Received: from fanzine.igalia.com ([178.60.130.6]:36126) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaZbu-0004x2-Nd; Mon, 18 May 2020 02:50:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=jBxaF/bIIMY7CrAuMCEsWGy1XswTC8pilqjewIpRh+Y=; b=GJR2y67DPtlP3YW+Zln7P4I86dBBSoHQbvhSX5pMrefpiFwWTT1ivTLEi86KJhCT1vg+/86ufj5cD4qmMjl5IRf0CknWYz4pX6eE0yfTspmPczBztfFVdxjNJHIvh+OVRCz4qCOL3qwzVOXPy0koPLfYHsAJEsFW+WymDZmjNPesHfMWiIgVvi3yaJ7g/u1tRC2vWVBcZEkcahapeq3kT50/+Zk47zi4YO5oXmYvxJ+O5IV+QWkXcpVbLz2KBjA6dFVSD5pzqUFIDmWbM6/JgyYiPYHUm3jDGM8BDDlgGLgdHYMsv/Re+Eb9EiqA1e5k8hY6+Yy38IvBK3ow1oW13Q==; Original-Received: from 82-65-63-215.subs.proxad.net ([82.65.63.215] helo=milano) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1jaZbW-0000eK-Ti; Mon, 18 May 2020 08:50:27 +0200 In-Reply-To: <871rninskn.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 17 May 2020 23:46:00 +0200") Received-SPF: pass client-ip=178.60.130.6; envelope-from=wingo@igalia.com; helo=fanzine.igalia.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/18 02:50:27 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:20526 Archived-At: On Sun 17 May 2020 23:46, Ludovic Court=C3=A8s writes: > The libunistring functions can take a pre-allocated buffer, but they > always malloc a fresh one if needed. So the best we could do is have a > =E2=80=98scm_to_stringn=E2=80=99 variant that takes a buffer, but it=E2= =80=99s not guaranteed > that it=E2=80=99ll actually be used. All in all, it seems the added comp= lexity > is not warranted. The worst case of =E2=80=98scm_locale_string_data=E2= =80=99 is also > rare enough. > > Thoughts? Interesting. Probably we want to make a public scm_to_{,locale_,utf8_}gc_string{,n} API and use that as a fallback. GC-managed character buffers are less error-prone and probably just as fast. We can mostly avoid the double-copy by inline conversions, as we do with UTF-8. For narrow strings scm_to_gc_stringn can always run iconv in a mode that just calculates output byte size; surely equivalent functionality is available from unistring, also. Andy