GNU bug report logs -
#58966
[Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate sprintf()
Previous Next
To reply to this bug, email your comments to 58966 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
[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):
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):
> 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):
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: 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):
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):
[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):
[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):
[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):
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):
[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):
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):
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):
[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):
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):
[[[ 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):
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):
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):
[[[ 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.