Re: Possible off-by-one bug in usr.sbin/rad/engine.c

Hello Rudolf, On 1/1/23 16:59, Rudolf Leitgeb wrote: Coming from a C/C++ background, I would assume, that a range from 200 to 600 comprises numbers would start at 200 and reach as far as 599. This would be in sync with all STL functions for iterating through collections or for extracting ranges.

Re: Possible off-by-one bug in usr.sbin/rad/engine.c

On 1/1/23 14:48, Alejandro Colomar wrote: Hello Florian, Ingo, On 1/1/23 08:24, Florian Obser wrote: On 2022-12-31 23:54 +01, Ingo Schwarze wrote: [...] With your change, the timeout could go up to 600.99, i.e. almost 601 seconds.  I don't know the protocol and can't s

Re: Possible off-by-one bug in usr.sbin/rad/engine.c

Hello Florian, Ingo, On 1/1/23 08:24, Florian Obser wrote: On 2022-12-31 23:54 +01, Ingo Schwarze wrote: Hi Alejandro, Alejandro Colomar wrote on Sat, Dec 31, 2022 at 05:56:27PM +0100: I've started auditing the OpenBSD source code after the discussion on arc4random_uniform(3) a

[RFC v1 2/2] Use arc4random_range() instead of arc4random_uniform() when appropriate

random_uniform(num2 - num3 + 1) + num3; + num1 = arc4random_range(num1, num2); Signed-off-by: Alejandro Colomar --- games/boggle/boggle/bog.c | 2 +- games/canfield/canfield/canfield.c | 2 +- games/mille/init.c

[RFC v1 1/2] Add arc4random_range(min, max)

Signed-off-by: Alejandro Colomar --- Hi, The patch to the manual page is still a draft; I know it has formatting issues; I don't know mdoc(7) enough to write in it. I CCd Ingo so that he may help me improve it. Theo, and any others, please consider the addition of this function, sin

Possible off-by-one bug in usr.sbin/rad/engine.c

Hi Theo and Florian, I've started auditing the OpenBSD source code after the discussion on arc4random_uniform(3) and my suggestion of arc4random_range() on the glibc mailing list. I found some cases where it seems like there's an off-by-one bug, which would be solved by providing arc4random_

readpassphrase(3) buffer needs explicit_bzero(3) on error?

Hi, I'd like to clarify if it's necessary to clear the buffer in the case that the function failed. Most errors seem to be clearly triggered before the first byte is written to the buffer: EINVAL, EIO, EMFILE, ENFILE, ENOTTY. But there is one, EINTR, which is not clear if there was any data

bind(2) documentation about the socklen_t parameter

h, so it is even more important to document it in detail. I more or less know how bind(2) works regarding socklen_t, but am not comfortable enough to write documentation about it. Would you mind documenting it in OpenBSD, so that it may help me document it in Linux? Cheers, Alex --