missing regex fix from FreeBSD?

2019-02-04 Thread enh
it seems like OpenBSD did cherrypick this FreeBSD regex fix... https://github.com/freebsd/freebsd/commit/981dd2aa38f37e4d0dd86225c619e900fc03d82e#diff-d7c26714f9432399b202eefcedb97491 ...but not this one, which also seems to apply to the OpenBSD copy of the code?

Re: missing regex fix from FreeBSD?

2019-02-05 Thread enh
On Mon, Feb 4, 2019 at 7:00 PM Ted Unangst wrote: > > enh wrote: > > it seems like OpenBSD did cherrypick this FreeBSD regex fix... > > > > https://github.com/freebsd/freebsd/commit/981dd2aa38f37e4d0dd86225c619e900fc03d82e#diff-d7c26714f9432399b202eefcedb97491 > &g

__hldtoa broken for ld128

2020-04-10 Thread enh
this was found by fuzzing the LLVM __cxa_demangle on an ld128 Android system using hwasan, but it turns out no to simply be a buffer overflow --- the results are just wrong. (which shows how much anyone uses ld128 in conjunction with %a!) this was the minimized test case:

Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)

2021-06-17 Thread enh
it's perhaps worth mentioning in the "pros" column that toybox (a 0BSD-licensed busybox which provides most of /bin on Android, which i maintain) and busybox both use Gavin's bc/dc implementations[1]. so although the GNU versions are their own thing and i assume likely to stay that way, "all

Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)

2021-06-17 Thread enh
On Thu, Jun 17, 2021 at 9:48 AM Otto Moerbeek wrote: > On Thu, Jun 17, 2021 at 10:01:02AM -0600, Gavin Howard wrote: > > > Otto, > > > > > I think it is interesting. As for the incompatibilites, my memory says > > > I followed the original dc and bc when deciding on those (GNU chose to > > >

Re: Possible bug in lib/libc/gen/exec.c

2021-09-16 Thread enh
we had the same issue in bionic when we removed all our alloca()s, modulo the fact that ours is a VLA rather than alloca(), but same thing: https://android.googlesource.com/platform/bionic/+/master/libc/bionic/exec.cpp#61 we argued that it doesn't matter in this case though because we'll touch

missing FreeBSD stdio patch

2023-10-03 Thread enh
looks like OpenBSD is missing this patch from FreeBSD? llvm libc++ hit this (a test worked on other OSes, including FreeBSD-based macOS) but failed on OpenBSD-based Android. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=127335 was the original FreeBSD bug report. POSIX seems to explicitly

Re: missing FreeBSD stdio patch

2023-10-04 Thread enh
On Wed, Oct 4, 2023 at 12:46 PM Todd C. Miller wrote: > > On Wed, 04 Oct 2023 11:53:51 -0600, Todd C. Miller wrote: > > > Yes, this should be fixed. One difference is that in FreeBSD, > > __swsetup() sets errno whereas in OpenBSD we set errno in the caller > > when cantwrite() is true. I think

setvbuf.c: fix 32-bit-ism

2022-09-27 Thread enh
The existing test is wrong for LP64, where size_t has twice as many relevant bits as int, not just one. (Found by inspection by rprichard.) diff --git a/lib/libc/stdio/setvbuf.c b/lib/libc/stdio/setvbuf.c index 9a08d133f5f..9909dbb8ecd 100644 --- a/lib/libc/stdio/setvbuf.c +++

Re: strptime.c

2023-01-26 Thread enh
well, the + if (bp == old_bp || errno == ERANGE || +((long) t) != n) return NULL; bit is the "most active ingredient" here, deliberately failing (rather than wrapping) if out of 32-bit range. it's quite possible that this could use _conv_num64(), but it wasn't obvious to me that that

Re: strptime.c

2023-01-26 Thread enh
On Thu, Jan 26, 2023 at 9:42 AM Todd C. Miller wrote: > On Thu, 26 Jan 2023 09:36:52 -0800, enh wrote: > > > it's quite possible that this could use _conv_num64(), but it wasn't > > obvious to me that that function's correct? (i haven't thought too hard > > about the

Re: strptime.c

2023-01-26 Thread enh
On Thu, Jan 26, 2023 at 10:37 AM Todd C. Miller wrote: > On Thu, 26 Jan 2023 10:29:36 -0800, enh wrote: > > > yeah, but that's the copy & paste-o, no? (apologies if it's just too > early > > for me to be looking at code yet...) > > > > doesn't this need to

strptime.c

2023-01-23 Thread enh
i synced Android's strptime.c with openbsd's recently, getting rid of unnecessary/accidental differences. i'm left with the following, which i thought was interesting (the last one's probably the most interesting, so definitely stick around even if -- as is likely -- you don't care about/actively

Re: Bringing in OpenBSD

2023-08-07 Thread enh
(fwiw, Android has someone working on adding this header to upstream LLVM right now, so hopefully it should come "for free" in llvm 18. what, if anything, to _do_ with it is another question though :-) ) On Mon, Aug 7, 2023 at 9:09 AM Lucian Popescu wrote: > > Hi, > > I noticed that some parts

Re: Bringing in OpenBSD

2023-08-07 Thread enh
On Mon, Aug 7, 2023 at 9:48 AM Theo de Raadt wrote: > > enh wrote: > > > (fwiw, Android has someone working on adding this header to upstream > > LLVM right now, so hopefully it should come "for free" in llvm 18. > > what, if anything, to _d

BUFSIZ-related pessimization in fvwrite.c

2024-03-29 Thread enh
(if anyone knows the equivalent freebsd list, please add them --- this code is the same between all three bsds.) Apple patched their copy of the FreeBSD fvwrite.c to change BUFSIZ to INT_MAX to massively improve the performance of large unbuffered writes[1], and patched the buffered case to use