On Wed, Apr 12, 2023 at 5:07 AM Joerg Sonnenberger wrote:
>
> Am Wed, Apr 12, 2023 at 09:17:49AM - schrieb Michael van Elst:
> > jo...@bec.de (Joerg Sonnenberger) writes:
> >
> > >Which compiler from this century doesn't allocate stack space
> > >independent from the source order?
> >
> > gcc
On Tue, Nov 2, 2021 at 4:54 PM Carlo Arenas wrote:
>
> On Tue, Nov 2, 2021 at 3:17 PM RVP wrote:
> >
> > Carlo, can you see if that works with your use-case?
>
> I only have a slow OpenBSD VM with current to test, so I am building a
> port of your patch there (which s
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, 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 retu
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" | (
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
