GNU bug report logs - #58966
[Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate sprintf()

Previous Next

Package: emacs;

Reported by: Jacob Faibussowitsch <jacob.fai <at> gmail.com>

Date: Wed, 2 Nov 2022 13:57:02 UTC

Severity: minor

To reply to this bug, email your comments to 58966 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Wed, 02 Nov 2022 13:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jacob Faibussowitsch <jacob.fai <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 02 Nov 2022 13:57:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate sprintf()
Date: Wed, 2 Nov 2022 09:56:41 -0400
[Message part 1 (text/plain, inline)]
Fresh build this morning produces many such warnings. I have attached config.log and make.log:

buffer.c:1223:46: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
      AUTO_STRING_WITH_LEN (lnumber, number, sprintf (number, "-%d", i));
                                             ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
                                                      ^

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)
[config.log (application/octet-stream, attachment)]
[make.log (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 05:57:02 GMT) Full text and rfc822 format available.

Message #8 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
Cc: 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 03 Nov 2022 06:56:25 +0100
Jacob Faibussowitsch <jacob.fai <at> gmail.com> writes:

> Fresh build this morning produces many such warnings. I have attached
> config.log and make.log:
>
> buffer.c:1223:46: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
>       AUTO_STRING_WITH_LEN (lnumber, number, sprintf (number, "-%d", i));
>                                              ^

Yeah, I've got 14.1 over night now, too, and I now see the same :-(.

From a hort look, just replacing sprintf variants with snprintf variants
won't be enough.  Things like make_formatted_string would require
interface changes, for example.

I short, that looks to me like a ton of boring and potentially bug-prone
work.

What do the maintainers think about this?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 08:18:02 GMT) Full text and rfc822 format available.

Message #11 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 58966 <at> debbugs.gnu.org, jacob.fai <at> gmail.com
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 03 Nov 2022 10:16:48 +0200
> Cc: 58966 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Thu, 03 Nov 2022 06:56:25 +0100
> 
> Jacob Faibussowitsch <jacob.fai <at> gmail.com> writes:
> 
> > Fresh build this morning produces many such warnings. I have attached
> > config.log and make.log:
> >
> > buffer.c:1223:46: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
> >       AUTO_STRING_WITH_LEN (lnumber, number, sprintf (number, "-%d", i));
> >                                              ^
> 
> Yeah, I've got 14.1 over night now, too, and I now see the same :-(.
> 
> >From a hort look, just replacing sprintf variants with snprintf variants
> won't be enough.  Things like make_formatted_string would require
> interface changes, for example.
> 
> I short, that looks to me like a ton of boring and potentially bug-prone
> work.
> 
> What do the maintainers think about this?

If no better ideas come up, find a way to disable this bogus warning.
configure.ac has a block of lines that disable various warnings under
certain conditions, starting around line 1100.  There are specific
warnings disabled when the compiler is clang.  Add something there to
shut up this warning.

We aren't going to make any serious changes in this, certainly not
before the emacs-29 release branch is cut.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 09:02:02 GMT) Full text and rfc822 format available.

Message #14 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58966 <at> debbugs.gnu.org, jacob.fai <at> gmail.com
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 03 Nov 2022 10:00:59 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

> If no better ideas come up, find a way to disable this bogus warning.
> configure.ac has a block of lines that disable various warnings under
> certain conditions, starting around line 1100.  There are specific
> warnings disabled when the compiler is clang.  Add something there to
> shut up this warning.

Thanks.  That would be

diff --git a/configure.ac b/configure.ac
index 63cb9c412e..c9d1eb5709 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1144,6 +1144,12 @@ AC_DEFUN
     gl_WARN_ADD([-Wno-int-in-bool-context])
   fi
 
+  # Suppress deprecation warnings from using sprintf variants,
+  # starting with Xcode 14.1 on macOS 13.
+  if test $opsys = darwin; then
+    gl_WARN_ADD([-Wno-deprecated-declarations])
+  fi
+
   # This causes too much noise in the MinGW build
   if test $opsys = mingw32; then
     gl_WARN_ADD([-Wno-pointer-sign])

Ok to install?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 09:16:02 GMT) Full text and rfc822 format available.

Message #17 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 58966 <at> debbugs.gnu.org, jacob.fai <at> gmail.com
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 03 Nov 2022 11:15:33 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: jacob.fai <at> gmail.com,  58966 <at> debbugs.gnu.org
> Date: Thu, 03 Nov 2022 10:00:59 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If no better ideas come up, find a way to disable this bogus warning.
> > configure.ac has a block of lines that disable various warnings under
> > certain conditions, starting around line 1100.  There are specific
> > warnings disabled when the compiler is clang.  Add something there to
> > shut up this warning.
> 
> Thanks.  That would be
> 
> diff --git a/configure.ac b/configure.ac
> index 63cb9c412e..c9d1eb5709 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1144,6 +1144,12 @@ AC_DEFUN
>      gl_WARN_ADD([-Wno-int-in-bool-context])
>    fi
>  
> +  # Suppress deprecation warnings from using sprintf variants,
> +  # starting with Xcode 14.1 on macOS 13.
> +  if test $opsys = darwin; then
> +    gl_WARN_ADD([-Wno-deprecated-declarations])
> +  fi
> +
>    # This causes too much noise in the MinGW build
>    if test $opsys = mingw32; then
>      gl_WARN_ADD([-Wno-pointer-sign])
> 
> Ok to install?

Yes, but perhaps condition that on the version of the
compiler/Xcode/whatever?  I mean, could this warning be useful in some
other cases?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 09:37:02 GMT) Full text and rfc822 format available.

Message #20 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58966 <at> debbugs.gnu.org, jacob.fai <at> gmail.com
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 3 Nov 2022 10:36:14 +0100
On 03.11.22 10:15, Eli Zaretskii wrote:
>> Ok to install?
> 
> Yes, but perhaps condition that on the version of the
> compiler/Xcode/whatever?  I mean, could this warning be useful in some
> other cases?

I don't think it's useful otherwise, except for the obvious of course,
that it would be better to fix these cases, as the recent SQLite thing
showed.

Maybe we should remove that again once 29 is released?  If we find some
kind soul...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 14:41:02 GMT) Full text and rfc822 format available.

Message #23 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 3 Nov 2022 10:40:25 -0400
[Message part 1 (text/plain, inline)]
Hmm I see

commit d16494cffbed79a916482558ae5ed1bdcc67c88d
Author: Gerd Möllmann <gerd <at> gnu.org>
Date:   Thu Nov 3 10:39:37 2022 +0100

    Suppress deprecation warnings on macOS (bug#58966)

    * configure.ac (CHECK_LISP_OBJECT_TYPE): Add
    -Wno-deprecated-declarations for darwin.

Has been merged to master but I still get warnings, config.log and make.log attached. I have make bootstrapped’ multiple times, but warnings persist.

PS: While we're at it, the build also shows many undefined variable warnings:

In x-dnd-wheel-modifier-type:
x-dnd.el:748:25: Warning: reference to free variable ‘mouse-wheel-scroll-amount’

In x-dnd-mwheel-scroll:
x-dnd.el:785:29: Warning: reference to free variable ‘mouse-wheel-progressive-speed’
x-dnd.el:787:23: Warning: reference to free variable ‘mouse-wheel-tilt-scroll’
x-dnd.el:795:34: Warning: reference to free variable ‘mwheel-scroll-right-function’
x-dnd.el:796:32: Warning: reference to free variable ‘mwheel-scroll-down-function’
x-dnd.el:799:34: Warning: reference to free variable ‘mwheel-scroll-left-function’
x-dnd.el:800:32: Warning: reference to free variable ‘mwheel-scroll-up-function’
x-dnd.el:802:34: Warning: reference to free variable ‘mouse-wheel-flip-direction’

In haiku-dnd-wheel-modifier-type:
haiku-win.el:520:25: Warning: reference to free variable ‘mouse-wheel-scroll-amount’

In haiku-handle-drag-wheel:
haiku-win.el:543:21: Warning: reference to free variable ‘mwheel-scroll-up-function’
haiku-win.el:545:21: Warning: reference to free variable ‘mwheel-scroll-down-function’
haiku-win.el:546:34: Warning: reference to free variable ‘mouse-wheel-flip-direction’
haiku-win.el:547:34: Warning: reference to free variable ‘mwheel-scroll-right-function’
haiku-win.el:548:32: Warning: reference to free variable ‘mwheel-scroll-left-function’
haiku-win.el:571:39: Warning: reference to free variable ‘mouse-wheel-progressive-speed’


Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

[config.log (application/octet-stream, attachment)]
[make.log (application/octet-stream, attachment)]
[Message part 4 (text/plain, inline)]
> On Nov 3, 2022, at 05:36, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
> 
> 
> On 03.11.22 10:15, Eli Zaretskii wrote:
>>> Ok to install?
>> Yes, but perhaps condition that on the version of the
>> compiler/Xcode/whatever?  I mean, could this warning be useful in some
>> other cases?
> 
> I don't think it's useful otherwise, except for the obvious of course,
> that it would be better to fix these cases, as the recent SQLite thing
> showed.
> 
> Maybe we should remove that again once 29 is released?  If we find some
> kind soul...


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 14:44:02 GMT) Full text and rfc822 format available.

Message #26 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 3 Nov 2022 15:43:10 +0100
[Message part 1 (text/plain, inline)]
You need to invoke autogen.sh and then configure.

> Am 03.11.2022 um 15:40 schrieb Jacob Faibussowitsch <jacob.fai <at> gmail.com>:
> 
> Hmm I see
> 
> commit d16494cffbed79a916482558ae5ed1bdcc67c88d
> Author: Gerd Möllmann <gerd <at> gnu.org>
> Date:   Thu Nov 3 10:39:37 2022 +0100
> 
>    Suppress deprecation warnings on macOS (bug#58966)
> 
>    * configure.ac (CHECK_LISP_OBJECT_TYPE): Add
>    -Wno-deprecated-declarations for darwin.
> 
> Has been merged to master but I still get warnings, config.log and make.log attached. I have make bootstrapped’ multiple times, but warnings persist.
> 
> PS: While we're at it, the build also shows many undefined variable warnings:
> 
> In x-dnd-wheel-modifier-type:
> x-dnd.el:748:25: Warning: reference to free variable ‘mouse-wheel-scroll-amount’
> 
> In x-dnd-mwheel-scroll:
> x-dnd.el:785:29: Warning: reference to free variable ‘mouse-wheel-progressive-speed’
> x-dnd.el:787:23: Warning: reference to free variable ‘mouse-wheel-tilt-scroll’
> x-dnd.el:795:34: Warning: reference to free variable ‘mwheel-scroll-right-function’
> x-dnd.el:796:32: Warning: reference to free variable ‘mwheel-scroll-down-function’
> x-dnd.el:799:34: Warning: reference to free variable ‘mwheel-scroll-left-function’
> x-dnd.el:800:32: Warning: reference to free variable ‘mwheel-scroll-up-function’
> x-dnd.el:802:34: Warning: reference to free variable ‘mouse-wheel-flip-direction’
> 
> In haiku-dnd-wheel-modifier-type:
> haiku-win.el:520:25: Warning: reference to free variable ‘mouse-wheel-scroll-amount’
> 
> In haiku-handle-drag-wheel:
> haiku-win.el:543:21: Warning: reference to free variable ‘mwheel-scroll-up-function’
> haiku-win.el:545:21: Warning: reference to free variable ‘mwheel-scroll-down-function’
> haiku-win.el:546:34: Warning: reference to free variable ‘mouse-wheel-flip-direction’
> haiku-win.el:547:34: Warning: reference to free variable ‘mwheel-scroll-right-function’
> haiku-win.el:548:32: Warning: reference to free variable ‘mwheel-scroll-left-function’
> haiku-win.el:571:39: Warning: reference to free variable ‘mouse-wheel-progressive-speed’
> 
> 
> Best regards,
> 
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> 
[config.log (application/octet-stream, attachment)]
[make.log (application/octet-stream, attachment)]
[Message part 4 (text/plain, inline)]
> 
>> On Nov 3, 2022, at 05:36, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>> 
>> 
>> On 03.11.22 10:15, Eli Zaretskii wrote:
>>>> Ok to install?
>>> Yes, but perhaps condition that on the version of the
>>> compiler/Xcode/whatever?  I mean, could this warning be useful in some
>>> other cases?
>> 
>> I don't think it's useful otherwise, except for the obvious of course,
>> that it would be better to fix these cases, as the recent SQLite thing
>> showed.
>> 
>> Maybe we should remove that again once 29 is released?  If we find some
>> kind soul...
> 

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 14:49:02 GMT) Full text and rfc822 format available.

Message #29 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 3 Nov 2022 10:48:45 -0400
[Message part 1 (text/plain, inline)]
No such luck

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

[config_and_make.log (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
> On Nov 3, 2022, at 10:43, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
> 
> You need to invoke autogen.sh and then configure.
> 
>> Am 03.11.2022 um 15:40 schrieb Jacob Faibussowitsch <jacob.fai <at> gmail.com>:
>> 
>> Hmm I see
>> 
>> commit d16494cffbed79a916482558ae5ed1bdcc67c88d
>> Author: Gerd Möllmann <gerd <at> gnu.org>
>> Date:   Thu Nov 3 10:39:37 2022 +0100
>> 
>>   Suppress deprecation warnings on macOS (bug#58966)
>> 
>>   * configure.ac (CHECK_LISP_OBJECT_TYPE): Add
>>   -Wno-deprecated-declarations for darwin.
>> 
>> Has been merged to master but I still get warnings, config.log and make.log attached. I have make bootstrapped’ multiple times, but warnings persist.
>> 
>> PS: While we're at it, the build also shows many undefined variable warnings:
>> 
>> In x-dnd-wheel-modifier-type:
>> x-dnd.el:748:25: Warning: reference to free variable ‘mouse-wheel-scroll-amount’
>> 
>> In x-dnd-mwheel-scroll:
>> x-dnd.el:785:29: Warning: reference to free variable ‘mouse-wheel-progressive-speed’
>> x-dnd.el:787:23: Warning: reference to free variable ‘mouse-wheel-tilt-scroll’
>> x-dnd.el:795:34: Warning: reference to free variable ‘mwheel-scroll-right-function’
>> x-dnd.el:796:32: Warning: reference to free variable ‘mwheel-scroll-down-function’
>> x-dnd.el:799:34: Warning: reference to free variable ‘mwheel-scroll-left-function’
>> x-dnd.el:800:32: Warning: reference to free variable ‘mwheel-scroll-up-function’
>> x-dnd.el:802:34: Warning: reference to free variable ‘mouse-wheel-flip-direction’
>> 
>> In haiku-dnd-wheel-modifier-type:
>> haiku-win.el:520:25: Warning: reference to free variable ‘mouse-wheel-scroll-amount’
>> 
>> In haiku-handle-drag-wheel:
>> haiku-win.el:543:21: Warning: reference to free variable ‘mwheel-scroll-up-function’
>> haiku-win.el:545:21: Warning: reference to free variable ‘mwheel-scroll-down-function’
>> haiku-win.el:546:34: Warning: reference to free variable ‘mouse-wheel-flip-direction’
>> haiku-win.el:547:34: Warning: reference to free variable ‘mwheel-scroll-right-function’
>> haiku-win.el:548:32: Warning: reference to free variable ‘mwheel-scroll-left-function’
>> haiku-win.el:571:39: Warning: reference to free variable ‘mouse-wheel-progressive-speed’
>> 
>> 
>> Best regards,
>> 
>> Jacob Faibussowitsch
>> (Jacob Fai - booss - oh - vitch)
>> 
> <config.log><make.log>
>> 
>>> On Nov 3, 2022, at 05:36, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>>> 
>>> 
>>> On 03.11.22 10:15, Eli Zaretskii wrote:
>>>>> Ok to install?
>>>> Yes, but perhaps condition that on the version of the
>>>> compiler/Xcode/whatever?  I mean, could this warning be useful in some
>>>> other cases?
>>> 
>>> I don't think it's useful otherwise, except for the obvious of course,
>>> that it would be better to fix these cases, as the recent SQLite thing
>>> showed.
>>> 
>>> Maybe we should remove that again once 29 is released?  If we find some
>>> kind soul...
>> 


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 15:23:02 GMT) Full text and rfc822 format available.

Message #32 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 3 Nov 2022 16:22:29 +0100
On 03.11.22 15:48, Jacob Faibussowitsch wrote:
> No such luck

I just built again, and it seems to work as expected.  Here is what it did:

git clean -xdf
./autogen.sh
./configure
make -j8

Could you please try that?







Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 15:31:01 GMT) Full text and rfc822 format available.

Message #35 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 3 Nov 2022 11:30:19 -0400
[Message part 1 (text/plain, inline)]
Did not work I’m afraid. I did:

$ git clean -xdf
$ ./autogen.sh
$ ./configure \
  --prefix=/Users/jacobfaibussowitsch/soft/packages \
  CC=clang \
  CXX=clang++ \
  CFLAGS='-O3 -mtune=native -flto=thin -flto-jobs=7 -std=gnu17 -Wno-unused-command-line-argument -Wno-unknown-pragmas' \
  CXXFLAGS='-O3 -mtune=native -flto=thin -flto-jobs=7 -std=gnu++20 -Wno-unused-command-line-argument -Wno-unknown-pragmas' \
  LDFLAGS='-L/opt/homebrew/lib' \
  -C \
  --with-native-compilation \
  --with-gnutls \
  --without-x \
  --with-xml2 \
  --with-dbus \
  --with-modules \
  --with-json \
  --without-ns \
  --with-jpeg \
  --with-tiff \
  --with-gif \
  --with-png \
  --with-rsvg \
  --with-libsystemd \
  --with-cairo \
  --with-harfbuzz \
  --with-zlib \
  --with-toolkit-scroll-bars \
  --disable-gcc-warnings \
  --without-compress-install \
  --with-libgmp
$ make 2>&1 | tee make.log

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

[config.log (application/octet-stream, attachment)]
[make.log (application/octet-stream, attachment)]
[Message part 4 (text/plain, inline)]
> On Nov 3, 2022, at 11:22, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
> 
> On 03.11.22 15:48, Jacob Faibussowitsch wrote:
>> No such luck
> 
> I just built again, and it seems to work as expected.  Here is what it did:
> 
> git clean -xdf
> ./autogen.sh
> ./configure
> make -j8
> 
> Could you please try that?
> 
> 
> 


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 16:16:02 GMT) Full text and rfc822 format available.

Message #38 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 3 Nov 2022 17:15:46 +0100
On 03.11.22 16:30, Jacob Faibussowitsch wrote:
> Did not work I’m afraid. I did:
> 
> $ git clean -xdf
> $ ./autogen.sh
> $ ./configure \
>    --prefix=/Users/jacobfaibussowitsch/soft/packages \
>    CC=clang \
>    CXX=clang++ \
>    CFLAGS='-O3 -mtune=native -flto=thin -flto-jobs=7 -std=gnu17 -Wno-unused-command-line-argument -Wno-unknown-pragmas' \
>    CXXFLAGS='-O3 -mtune=native -flto=thin -flto-jobs=7 -std=gnu++20 -Wno-unused-command-line-argument -Wno-unknown-pragmas' \
>    LDFLAGS='-L/opt/homebrew/lib' \
>    -C \
>    --with-native-compilation \
>    --with-gnutls \
>    --without-x \
>    --with-xml2 \
>    --with-dbus \
>    --with-modules \
>    --with-json \
>    --without-ns \
>    --with-jpeg \
>    --with-tiff \
>    --with-gif \
>    --with-png \
>    --with-rsvg \
>    --with-libsystemd \
>    --with-cairo \
>    --with-harfbuzz \
>    --with-zlib \
>    --with-toolkit-scroll-bars \
>    --disable-gcc-warnings \
>    --without-compress-install \
>    --with-libgmp
> $ make 2>&1 | tee make.log
> 
> Best regards,

Then it's something in your configure args that's overwriting it.
It's apparently not the CFLAGS="...", that much I can tell.  Can you
find out?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 16:20:02 GMT) Full text and rfc822 format available.

Message #41 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Thu, 3 Nov 2022 17:19:03 +0100
On 03.11.22 17:15, Gerd Möllmann wrote:
> On 03.11.22 16:30, Jacob Faibussowitsch wrote:
>> Did not work I’m afraid. I did:
>>
>> $ git clean -xdf
>> $ ./autogen.sh
>> $ ./configure \
>>    --prefix=/Users/jacobfaibussowitsch/soft/packages \
>>    CC=clang \
>>    CXX=clang++ \
>>    CFLAGS='-O3 -mtune=native -flto=thin -flto-jobs=7 -std=gnu17 
>> -Wno-unused-command-line-argument -Wno-unknown-pragmas' \
>>    CXXFLAGS='-O3 -mtune=native -flto=thin -flto-jobs=7 -std=gnu++20 
>> -Wno-unused-command-line-argument -Wno-unknown-pragmas' \
>>    LDFLAGS='-L/opt/homebrew/lib' \
>>    -C \
>>    --with-native-compilation \
>>    --with-gnutls \
>>    --without-x \
>>    --with-xml2 \
>>    --with-dbus \
>>    --with-modules \
>>    --with-json \
>>    --without-ns \
>>    --with-jpeg \
>>    --with-tiff \
>>    --with-gif \
>>    --with-png \
>>    --with-rsvg \
>>    --with-libsystemd \
>>    --with-cairo \
>>    --with-harfbuzz \
>>    --with-zlib \
>>    --with-toolkit-scroll-bars \
>>    --disable-gcc-warnings \
>>    --without-compress-install \
>>    --with-libgmp
>> $ make 2>&1 | tee make.log
>>
>> Best regards,
> 
> Then it's something in your configure args that's overwriting it.
> It's apparently not the CFLAGS="...", that much I can tell.  Can you
> find out?
> 

Forgot the tell - it's WARN_FLAGS=... in src/Makefile that is changed by
some configure option.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Thu, 03 Nov 2022 18:31:01 GMT) Full text and rfc822 format available.

Message #44 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 58966 <at> debbugs.gnu.org
Subject: re: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate sprintf()
Date: Thu, 3 Nov 2022 11:30:50 -0700
[Message part 1 (text/plain, inline)]
It appears that Apple has gone on the warpath against sprintf even if 
you compile with plain 'gcc' with no options, which means 
--disable-gcc-warnings does not suppress the false alarms.

I installed the attached further patch to attempt to pacify Apple's 
compiler; please give it a try.

Perhaps Apple's compiler will start complaining about strcpy next....
[0001-Improve-suppression-of-bogus-macOS-warnings.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Fri, 04 Nov 2022 21:08:01 GMT) Full text and rfc822 format available.

Message #47 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 58966 <at> debbugs.gnu.org
Subject: Re: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate sprintf()
Date: Fri, 4 Nov 2022 17:07:09 -0400
Sorry for the delay. I just tested most recent master (most recent commit summary below):

commit 44ad42240069d8d82772b0c0ef5ec93c2566ca7e (HEAD -> master, origin/master, origin/HEAD)
Author: Stefan Kangas <stefankangas <at> gmail.com>
Date:   Fri Nov 4 20:26:01 2022 +0100

And I don’t see any warnings anymore -- I am assuming your commit made it in. Thanks for the fix.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

> On Nov 3, 2022, at 14:30, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> 
> It appears that Apple has gone on the warpath against sprintf even if you compile with plain 'gcc' with no options, which means --disable-gcc-warnings does not suppress the false alarms.
> 
> I installed the attached further patch to attempt to pacify Apple's compiler; please give it a try.
> 
> Perhaps Apple's compiler will start complaining about strcpy next....
> <0001-Improve-suppression-of-bogus-macOS-warnings.patch>





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Sat, 05 Nov 2022 03:13:02 GMT) Full text and rfc822 format available.

Message #50 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: gerd.moellmann <at> gmail.com, 58966 <at> debbugs.gnu.org, jacob.fai <at> gmail.com
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Fri, 04 Nov 2022 23:12:38 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We could switch to snprintf, and define snprintf to call sprintf
in systems where snprintf isn't available.  It is possible to verify
that sprintf did not overwrite the buffer.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Sat, 05 Nov 2022 16:27:01 GMT) Full text and rfc822 format available.

Message #53 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: rms <at> gnu.org
Cc: gerd.moellmann <at> gmail.com, jacob.fai <at> gmail.com,
 Paul Eggert <eggert <at> cs.ucla.edu>, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Sat, 5 Nov 2022 17:26:18 +0100
Richard Stallman <rms <at> gnu.org> writes:

> We could switch to snprintf, and define snprintf to call sprintf
> in systems where snprintf isn't available.

snprintf is part of the C99 standard, so I think we can always rely on
it being there.  Switching sounds like a good idea.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Sat, 05 Nov 2022 20:01:02 GMT) Full text and rfc822 format available.

Message #56 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Kangas <stefankangas <at> gmail.com>, rms <at> gnu.org
Cc: gerd.moellmann <at> gmail.com, jacob.fai <at> gmail.com, 58966 <at> debbugs.gnu.org
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Sat, 5 Nov 2022 13:00:25 -0700
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.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58966; Package emacs. (Mon, 07 Nov 2022 07:47:01 GMT) Full text and rfc822 format available.

Message #59 received at 58966 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: gerd.moellmann <at> gmail.com, 58966 <at> debbugs.gnu.org, stefankangas <at> gmail.com,
 jacob.fai <at> gmail.com
Subject: Re: bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate
 sprintf()
Date: Mon, 07 Nov 2022 02:46:45 -0500
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

I principle, yes.  But most of the calls to sprintf I saw seem to
generate output that is very limited in size, so there is no danger
of buffer overflow in practice.

  >  > 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,

What is hard about it?

  > > It is possible to verify
  > > that sprintf did not overwrite the buffer.

  > Sorry, I don't know what this comment is trying to say.

Sorry if that was too terse.

If we define snpritf to call sprintf on some platforms, as I suggested
as a fallback, that definition can check the return value of sprintf
to make sure that sprintf did not overflow the output buffer that
snprintf was given.  It can call fatal if that overflow occurs.

  > In my experience, with a debugging runtime sprintf is better than 
  > snprintf, as sprintf reliably reports bugs

What is a "debugging runtime"?

sprintf can't try to detect overflow of the output buffer, because
nothing tells sprintf how big the buffer is.



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Severity set to 'minor' from 'normal' Request was from Stefan Kangas <stefankangas <at> gmail.com> to control <at> debbugs.gnu.org. (Sat, 12 Nov 2022 20:35:06 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 137 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.