On Tue, Nov 02, 2021 at 04:54:58PM -0700, Carlo Arenas wrote:
> Note that the way the wording is done in that paragraph, it might seem
> to imply that the position is a property of the file and not of the
> FILE, so you could have more than one FILE pointing to the same fd,
> and any fseek on i
On Tue, Nov 2, 2021 at 3:17 PM RVP wrote:
>
> On Tue, 2 Nov 2021, Christos Zoulas wrote:
>
> > In article ,
> > RVP wrote:
> >>
> >> This looks like a useful behaviour to add to the libc close routines.
> >
> > I agree!
FWIW at least MUSL seems to be just doing an fflush(), which might be
the p
On Tue, 2 Nov 2021, Christos Zoulas wrote:
In article ,
RVP wrote:
This looks like a useful behaviour to add to the libc close routines.
I agree!
A first cut is something like this:
---START PATCH---
diff -urN stdio.orig/fclose.c stdio/fclose.c
--- stdio.orig/fclose.c 2012-03-15 18:22:
On Tue, 2 Nov 2021, Carlo Arenas wrote:
while troubleshooting a test failure for pcre2[0] in OpenBSD, tracked
down the problem to code that was inherited from NetBSD for their
fseek implementation in libc.
This isn't actually an fseek issue. Glibc and musl do an explicit lseek()
when closing
On Tue, Nov 2, 2021 at 11:39 AM Martin Husemann wrote:
>
> On Tue, Nov 02, 2021 at 10:53:55AM -0700, Carlo Arenas wrote:
> > Note that the failure in this case can be "fixed" by instead calling
> > lseek directly, removing the buffer or skipping this early return in
> > src/lib/libc/stdio/fseeko.c
On Tue, Nov 02, 2021 at 10:53:55AM -0700, Carlo Arenas wrote:
> Note that the failure in this case can be "fixed" by instead calling
> lseek directly, removing the buffer or skipping this early return in
> src/lib/libc/stdio/fseeko.c (lines 210 to 228), and that I am showing
> below (might be mangl
On Tue, Nov 2, 2021 at 8:54 AM Rhialto wrote:
>
> This can never work in the presence of buffering (which is likely
> allowed by the C Standard, but I didn't look that up), because not all
> input is seekable. This variant "fails" equally on Linux, MacOS and
> NetBSD:
>
> $ printf "1\n2\n3\n" | (
On Tue 02 Nov 2021 at 03:48:36 -0700, Carlo Arenas wrote:
> the following works in Windows/Linux/macOS :
>
> $ printf "1\n2\n3\n" > i && ( head -1; head -1; cat ) < i && rm -f i
> 1
> 2
> 3
>
> but only works in recent NetBSD if STDBUF0=U is set (which is not
> available in OpenBSD or other der
Greetings,
while troubleshooting a test failure for pcre2[0] in OpenBSD, tracked
down the problem to code that was inherited from NetBSD for their
fseek implementation in libc.
it can be worked around by calling lseek directly or by removing the
buffer, which would seem not to be updated if the s
> Date: Wed, 20 Oct 2021 14:37:41 -0700
> From: Alistair Crooks
>
> I think it's a good idea, BUT I'd be a lot happier if the argon2 support
> was in a regular release (I know it's just the default cipher going
> forward, but I suspect some people have got into the nasty habit of cloning
> some o
On Sun, Oct 31, 2021 at 04:45:59PM -0700, Alistair Crooks wrote:
> Or is the intent to discuss this in retrospect?
Is the concern primarily with it not being in a release?
I'm not really certain how I could address it, other than a prerequisite
waiting a few years. It's true that existing passwor
11 matches
Mail list logo
