Hello Theo,
On 9/16/21 10:53 PM, Theo de Raadt wrote:
@@ -45,25 +46,31 @@ execl(const char *name, const char *arg,
{
va_list ap;
char **argv;
- int n;
+ size_t maplen;
+ int save_errno, n, error;
See below.
va_start(ap, arg);
n = 1;
w
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
all
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:
> Hel
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.
>
> writer
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 br
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 argue
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 ha
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
> e
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 sysctl(8)/se
> 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 informatio
12 matches
Mail list logo
