warn against strcpy(3)

2022-10-03 Thread Jan Schaumann
Hello, On macOS, the strcpy(3) manual page contains the following "Admonishment" prominently displayed immediately after the Synopsis: YOU SHOULD ALMOST CERTAINLY USE strlcpy() INSTEAD. See "Examples" below. (Likewise for strcat(3).) I find this a rather effective way of discouraging its use es

Re: alloca again

2022-10-03 Thread David Holland
On Tue, Oct 04, 2022 at 12:41:07AM +0300, Valery Ushakov wrote: > On Mon, Oct 03, 2022 at 18:32:47 +, David Holland wrote: > > > On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote: > > > > This is the current alloca definition in the libc headers: > > > > > > > > #if define

Re: alloca again

2022-10-03 Thread Joerg Sonnenberger
On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote: > I'd argue that providing alloca(3) as anything except a compiler > builtin is a bug, and that kind of thing should never be used. Well, if you are in strict C/C++ standard mode, alloca should not exist because it is not part of the standard. I

Re: alloca again

2022-10-03 Thread Valery Ushakov
On Mon, Oct 03, 2022 at 18:32:47 +, David Holland wrote: > On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote: > > > This is the current alloca definition in the libc headers: > > > > > > #if defined(_NETBSD_SOURCE) > > > #if defined(alloca) && (alloca == __builtin_alloca) && \

Re: alloca again

2022-10-03 Thread Mouse
> If you would like to contribute to an effort to fumigate pkgsrc for > alloca uses, please go ahead. [...] However, iirc you won't touch > pkgsrc for some reason :-p Not so much "won't" has "have no reason to". pkgsrc, at least last I checked, makes no attempt to be useful to me, to support Ne

Re: alloca again

2022-10-03 Thread David Holland
On Mon, Oct 03, 2022 at 02:20:20PM -0400, Mouse wrote: > >>> #if defined(_NETBSD_SOURCE) > >>> #if defined(alloca) && (alloca == __builtin_alloca) && \ > >> [...] > > _NETBSD_SOURCE and __builtin_alloca are each in reserved-for-any-use > > namespace, so there are no grounds for citing the stan

Re: alloca again

2022-10-03 Thread David Holland
On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote: > > This is the current alloca definition in the libc headers: > > > > #if defined(_NETBSD_SOURCE) > > #if defined(alloca) && (alloca == __builtin_alloca) && \ > > According to my knowledge of the C preprocessor, the condition 'a

Re: alloca again

2022-10-03 Thread Mouse
>>> #if defined(_NETBSD_SOURCE) >>> #if defined(alloca) && (alloca == __builtin_alloca) && \ >> [...] > _NETBSD_SOURCE and __builtin_alloca are each in reserved-for-any-use > namespace, so there are no grounds for citing the standard as basis > for any behaviour whatsoever from that. I think I ove

Re: alloca again

2022-10-03 Thread David Holland
On Mon, Oct 03, 2022 at 09:33:47AM -0400, Mouse wrote: > >>> I'd argue that providing alloca(3) as anything except a compiler > >>> builtin is a bug, and that kind of thing should never be used. > >> I'd argue that alloca should never be used and actually should never > >> have existed. As far

Re: alloca again

2022-10-03 Thread Mouse
>> #if defined(_NETBSD_SOURCE) >> #if defined(alloca) && (alloca == __builtin_alloca) && \ > According to my knowledge of the C preprocessor, the condition > 'alloca == __builtin_alloca' always evaluates to '0 == 0', assuming > that if 'alloca' and '__builtin_alloca' are actually defined, they > e

Re: alloca again

2022-10-03 Thread Roland Illig
Am 03.10.2022 um 14:31 schrieb nia: This is the current alloca definition in the libc headers: #if defined(_NETBSD_SOURCE) #if defined(alloca) && (alloca == __builtin_alloca) && \ According to my knowledge of the C preprocessor, the condition 'alloca == __builtin_alloca' always evaluates to '0

Re: alloca again

2022-10-03 Thread Mouse
>>> I'd argue that providing alloca(3) as anything except a compiler >>> builtin is a bug, and that kind of thing should never be used. >> I'd argue that alloca should never be used and actually should never >> have existed. As far as I can see it does nothing that can't be >> done better - more p

Re: alloca again

2022-10-03 Thread nia
On Mon, Oct 03, 2022 at 08:45:33AM -0400, Mouse wrote: > > I'd argue that providing alloca(3) as anything except a compiler > > builtin is a bug, and that kind of thing should never be used. > > I'd argue that alloca should never be used and actually should never > have existed. As far as I can s

Re: alloca again

2022-10-03 Thread Mouse
> I'd argue that providing alloca(3) as anything except a compiler > builtin is a bug, and that kind of thing should never be used. I'd argue that alloca should never be used and actually should never have existed. As far as I can see it does nothing that can't be done better - more portably and

Re: alloca again

2022-10-03 Thread nia
On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote: > Is there any reason we don't simplify this in the headers - > __builtin_alloca(size) seems to work with every compiler? I forgot to add: __builtin_alloca works with -std=c99, with GCC and clang.

alloca again

2022-10-03 Thread nia
This TODO item has been in libc's shlib_version file for ages: "remove alloca fallback and expect compiler to provide a builtin version." On various architectures (powerpc, aarch64), pkgsrc bulk build reports are filled with the following error: "undefined reference to `alloca'" On other archit