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
It always returns -1 until the world changes in some subtle way,
then the code is wrong.
The logic is supposed to return what execve returns, not reinvent
the value.
Over decades this kind of assumption can turn into a bug, so I
prefer to do it right.
Alejandro Colomar (man-pages) wrote:
>
On Thu, Sep 16, 2021 at 11:00:31PM +0200, Kristaps Dzonsons wrote:
> Hi,
>
> I'm porting a nonblocking, polling OpenSSL system to libtls. However, I'm
> not sure how this is non-hackily possible without SSL_pending(3) to detect
> if less data is read with tls_read() than is buffered.
>
>
Interestingly, there was a long discussion over beer at a hackathon
recently, about non-blocking and poll/select/kqueue/etc, in particular
when mixed with TLS codepaths.
In my view, mixing poll()-style event loops with non-blocking
descriptors will -- 99% of the time -- result in people writing
enh wrote:
> 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
that cargo culting doesn't fix anything...
> we
Hi,
I'm porting a nonblocking, polling OpenSSL system to libtls. However,
I'm not sure how this is non-hackily possible without SSL_pending(3) to
detect if less data is read with tls_read() than is buffered.
writer:
tls_write(40)
reader:
poll(POLLIN, INFTIM) -> POLLIN /* descriptor
Theo de Raadt wrote:
> Maybe we should investigate using mmap. Of the 4 cases, 3 are not
> too difficult, but the 4th case will be very messy, including unwind
> for the 3rd case.
Here is a version that uses mmap instead of alloca, including rollback
of resource allocations in case of failure.
Alejandro Colomar (man-pages) wrote:
> Hi,
>
> I don't know if OpenBSD has a different implementation of alloca(3)
> than Linux. In Linux, alloca(3) (a.k.a. __builtin_alloca()) can't
> return NULL, as it can't detect errors.
There are no alloca can return NULL.
> The only way to detect an
>
Hi,
I don't know if OpenBSD has a different implementation of alloca(3) than
Linux. In Linux, alloca(3) (a.k.a. __builtin_alloca()) can't return
NULL, as it can't detect errors. The only way to detect an error is to
add a handler for SIGSEGV, AFAIK.
I found the following code in :
> Date: Thu, 16 Sep 2021 06:12:39 +
> From: Klemens Nanni
>
> On 3 September 2021 20:16:33 GMT+05:00, Klemens Nanni
> wrote:
> >Here is a tiny driver enabling machines such as the Pinebook Pro to
> >indicate power, it is intentionally minimal and does not expose anything
> >via
> Date: Thu, 16 Sep 2021 06:14:39 +
> From: Klemens Nanni
>
> On 5 September 2021 01:22:53 GMT+05:00, Klemens Nanni
> wrote:
> >Read a single GPIO pin indicating whether AC is plugged in or not.
> >
> >This gives me a sensor on my Pinebook Pro.
> >cwfg(4) already provides battery
On 3 September 2021 20:16:33 GMT+05:00, Klemens Nanni wrote:
>Here is a tiny driver enabling machines such as the Pinebook Pro to
>indicate power, it is intentionally minimal and does not expose anything
>via sysctl(8)/sensorsd(8) or gpioctl(8).
>
>This is helpful for machines where graphics,
On 5 September 2021 01:22:53 GMT+05:00, Klemens Nanni wrote:
>Read a single GPIO pin indicating whether AC is plugged in or not.
>
>This gives me a sensor on my Pinebook Pro.
>cwfg(4) already provides battery information but not the charger bits.
>
>apm(4) integration can follow separately.
>
13 matches
Mail list logo
