Re: best way to deal with macOS deprecation of sprintf?

Paul Eggert wrote: > As noted in , macOS 13.0 has deprecated > sprintf, on the grounds that buffer overflow happens too often with it. > As a result, compilers will complain about any calls to sprintf, even if > you don't configure with --enable-gcc-warnings. I

Re: best way to deal with macOS deprecation of sprintf?

On 11/3/22 12:43, Jeffrey Walton wrote: Apple deprecated sprintf starting at MacOS 10.12. Yes, though that change in 10.12 apparently didn't adversely affect developers. What appears to be new in 10.13 is that the compiler is now warning about calls to sprintf. This is an unnecessary pain.

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

On 11/3/22 13:40, Karl Berry wrote: Whatever happens, can one of you make the desired changes in gnulib? Already done and installed, here: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=ddfcbc95a6be3ddc588a93f21edb69cc7c214d9c As part of that patch, I did the same sort of sync that

Re: best way to deal with macOS deprecation of sprintf?

Jeffrey Walton wrote: > snprintf is kind of a lame for a replacement since it backfills the > buffer with all 0's. Nope, it doesn't. [1] You must be confusing it with strncpy(), which fills all the buffer. [2] Bruno [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html [2]

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

Paul Eggert wrote: > > Here are proposed patches to rename the modules. > > Thanks, those look good to me too. Thanks for the review. Pushed. Bruno

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

Whatever happens, can one of you make the desired changes in gnulib? I have never tried to follow the glibc/gnulib stuff. This one is above my pay grade :). I just blindly sync the changes ... --thanks, karl.

Re: best way to deal with macOS deprecation of sprintf?

On Thu, Nov 3, 2022 at 3:23 PM Paul Eggert wrote: > > As noted in , macOS 13.0 has deprecated > sprintf, on the grounds that buffer overflow happens too often with it. > As a result, compilers will complain about any calls to sprintf, even if > you don't configure with

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

* Paul Eggert: > What problems do you see with the interfaces, and are there efforts to > come up with a better API? The need is there in GNU apps, each of > which tends to roll its own code here. dynarray has an aliasing violation in its implementation. The embedded pointer should be void *

best way to deal with macOS deprecation of sprintf?

As noted in , macOS 13.0 has deprecated sprintf, on the grounds that buffer overflow happens too often with it. As a result, compilers will complain about any calls to sprintf, even if you don't configure with --enable-gcc-warnings. I assume vsprintf is similar.

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

On 2022-11-03 05:41, Bruno Haible wrote: Here are proposed patches to rename the modules. Thanks, those look good to me too.

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

On 2022-11-03 04:03, Florian Weimer wrote: I must say I was surprised to see dynarray and scratch_buffer end up in gnulib. I never intended them to escape this way from glibc. They escaped from glibc because they're used by code shared with Gnulib (e.g., canonicalize.c). The interfaces

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

Florian Weimer wrote: > > But it means that we cannot promise that these .h files are even remotely > > stable APIs. > > I must say I was surprised to see dynarray and scratch_buffer end up in > gnulib. I never intended them to escape this way from glibc. The > interfaces and their

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

* Bruno Haible: > But when it comes to scratch_buffer or dynarray code, this week's experience > has shown that we cannot count on as much care for Gnulib users. Rather, > the mindset on the glibc side seems to be: "This is glibc internal code; > we can refactor / reshuffle / trim it as we like."

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

Hi Paul, Paul Eggert wrote: > > In other words, I'm suggesting to rename the modules > >scratch_buffer -> glibc-internal/scratch_buffer > >dynarray -> glibc-internal/dynarray > > I don't see any problem with that, since as far as I know the only > current users of the two modules