Index | Thread | Search

From:
Christian Schulte <cs@schulte.it>
Subject:
Re: Maybe strlen is unnecessary in kern_unveil.c
To:
Theo de Raadt <deraadt@openbsd.org>, Sebastien Marie <semarie@kapouay.eu.org>
Cc:
Bob Beck <beck@obtuse.com>, tech@openbsd.org
Date:
Thu, 20 Nov 2025 07:05:31 +0100

Download raw body.

Thread
Am 19.11.2025 um 18:00 schrieb Theo de Raadt:
> I've seen so much trouble from taking a buffer, which is not actually
> a string, and start trying to add half-measures to NUL terminate or
> or check for NUL-termination, so that is now kind of like a string.
> Soon, someone dealing with the code sees those checks and starts to
> believe it is a string but it isn't, and now a bug gets introduced,
> and quite often these problems are related to the +1 accounting for
> the NUL.  Like here :)
> 
> So my gut feeling has always been that if an object is a non-string buffer,
> every single line of code should treat it like a non-string to avoid
> the confusion.
> 

You just drove me into booting my Falcon030 and compare Pure Pascal to
Pure C with regard to string handling. Passing a string around in
Pascal, that string implicitly carries a length property. Passing a
string around in C, that string does not carry any implicit properties
denoting it a string. In C, just never pass a char * without a
corresponding size_t denoting buffer/string length. I am still confused
about that memcmp in kern_unveil.c, though. Seems to be a very clever
trick to include string termination in that comparison, I am just not
getting yet.