From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate sprintf() Date: Sat, 5 Nov 2022 13:00:25 -0700 Organization: UCLA Computer Science Department Message-ID: References: <91d5853d-b810-3b69-93cf-772c81c34f7e@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17050"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Cc: gerd.moellmann@gmail.com, jacob.fai@gmail.com, 58966@debbugs.gnu.org To: Stefan Kangas , rms@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 05 21:01:48 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1orPMR-00048q-LN for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Nov 2022 21:01:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orPM0-0006Sa-KJ; Sat, 05 Nov 2022 16:01:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orPLi-0006S8-Gh for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 16:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1orPLi-00053l-7X for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 16:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1orPLi-0000YY-3E for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 16:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2022 20:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58966 X-GNU-PR-Package: emacs Original-Received: via spool by 58966-submit@debbugs.gnu.org id=B58966.16676784412106 (code B ref 58966); Sat, 05 Nov 2022 20:01:02 +0000 Original-Received: (at 58966) by debbugs.gnu.org; 5 Nov 2022 20:00:41 +0000 Original-Received: from localhost ([127.0.0.1]:58138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orPLN-0000Xu-FL for submit@debbugs.gnu.org; Sat, 05 Nov 2022 16:00:41 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orPLI-0000Xc-Bd for 58966@debbugs.gnu.org; Sat, 05 Nov 2022 16:00:40 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F26C716007F; Sat, 5 Nov 2022 13:00:29 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Ub5Ry0jKh2Bn; Sat, 5 Nov 2022 13:00:25 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C2B82160080; Sat, 5 Nov 2022 13:00:25 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu C2B82160080 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1667678425; bh=/WCI5oncDSbQmSIYBNkustuvisZJU9mt6Nh55GRGLco=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=L+J9mIsb/T8EjOYIcj0OO/yQkdJ/Th+rdvvbLn2Hvgt5spjkdHlXl3I29bbzIek9t +yvgelG115/bHApJZx2wYISkOgEZAVmel6MbwBzcfDIj19EypD2Ki4ncWCRlQy7qGP JAQfBarjWegMoCBbyIkDJUgWETDF6ZJBfxC8HFTo= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PhaDMaZV8Y9s; Sat, 5 Nov 2022 13:00:25 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8443F16007F; Sat, 5 Nov 2022 13:00:25 -0700 (PDT) Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247157 Archived-At: On 2022-11-05 09:26, Stefan Kangas wrote: > snprintf is part of the C99 standard, so I think we can always rely on > it being there. Switching sounds like a good idea. sprintf is also part of the C99 (and C17 and C23) standards, so "it's in the standard" does not mean we need to switch away from sprintf. While we're on the topic: sprintf and snprintf both have serious design flaws, in that they cannot generate output longer than INT_MAX bytes, and this contradicts the GNU design philosophy to avoid arbitrary limits. Instead, code that needs low level formatting should use Emacs's own esprintf family of functions, which don't have the INT_MAX limit. (Often it's better for code to use Fformat etc. and generate a Lisp string, which doesn't have that limit either.) Admittedly we haven't always been good about this, as sprintf/snprintf are standard and are tempting to use. It might be a good idea, though, for someone to go through the code and see if there are any INT_MAX-related bugs lurking in Emacs now due to its use of sprintf and/or snprintf, and replace these calls with something better. On 2022-11-04 20:12, Richard Stallman wrote: > We could switch to snprintf, and define snprintf to call sprintf > in systems where snprintf isn't available. That wouldn't that easy to do, and would make code more awkward and slow it down a bit. The current 3-line change to configure.ac is much simpler. It's pretty implausible that Apple will make sprintf go away entirely - and if Apple is foolish enough to do so, there are simple workarounds for that that don't involve messing with our legacy code. > It is possible to verify > that sprintf did not overwrite the buffer. Sorry, I don't know what this comment is trying to say. In my experience, with a debugging runtime sprintf is better than snprintf, as sprintf reliably reports bugs whereas snprintf silently truncates and continues with hard-to-debug behavior occuring later. Of course with traditional non-debugging runtimes one loses with sprintf, but in practice it's a tradeoff often worth making.