* bug in roundup(3) from <sys/param.h>
@ 2023-01-17 19:16 Wilco Dijkstra
2023-01-17 19:50 ` Alejandro Colomar
2023-01-17 20:11 ` Paul Eggert
0 siblings, 2 replies; 7+ messages in thread
From: Wilco Dijkstra @ 2023-01-17 19:16 UTC (permalink / raw)
To: Adhemerval Zanella, Alejandro Colomar (man-pages); +Cc: 'GNU C Library'
Hi,
> I really won't bother with this interface, since potentially changing it
> might generate more potentially breakage than improvements.
The typical use-case is rounding up a pointer to align it or increasing a buffer
to be allocated. There is no chance of overflow in these cases since you will
never have pointers that close to SIZE_MAX or get buffers close to the maximum
memory size. And adding saturation would mean we didn't do what was requested
either...
So it seems best to state it only works on unsigned values (with y > 0 since division
by zero is undefined behaviour of course) and it's implementation defined whether
overflow wraps or saturates.
Cheers,
Wilco
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: bug in roundup(3) from <sys/param.h>
2023-01-17 19:16 bug in roundup(3) from <sys/param.h> Wilco Dijkstra
@ 2023-01-17 19:50 ` Alejandro Colomar
2023-01-17 20:11 ` Paul Eggert
1 sibling, 0 replies; 7+ messages in thread
From: Alejandro Colomar @ 2023-01-17 19:50 UTC (permalink / raw)
To: Wilco Dijkstra, Adhemerval Zanella; +Cc: 'GNU C Library'
[-- Attachment #1.1: Type: text/plain, Size: 935 bytes --]
Hi Wilco and Adhemerval!
On 1/17/23 20:16, Wilco Dijkstra wrote:
> Hi,
>
>> I really won't bother with this interface, since potentially changing it
>> might generate more potentially breakage than improvements.
>
> The typical use-case is rounding up a pointer to align it or increasing a buffer
> to be allocated. There is no chance of overflow in these cases since you will
> never have pointers that close to SIZE_MAX or get buffers close to the maximum
> memory size. And adding saturation would mean we didn't do what was requested
> either...
>
> So it seems best to state it only works on unsigned values (with y > 0 since division
> by zero is undefined behaviour of course) and it's implementation defined whether
> overflow wraps or saturates.
>
Thanks! That clarifies what this macro is for. I'll document that.
Cheers,
Alex
> Cheers,
> Wilco
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: bug in roundup(3) from <sys/param.h>
2023-01-17 19:16 bug in roundup(3) from <sys/param.h> Wilco Dijkstra
2023-01-17 19:50 ` Alejandro Colomar
@ 2023-01-17 20:11 ` Paul Eggert
2023-01-17 20:13 ` Alejandro Colomar
1 sibling, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2023-01-17 20:11 UTC (permalink / raw)
To: Wilco Dijkstra, Adhemerval Zanella, Alejandro Colomar (man-pages)
Cc: 'GNU C Library'
On 1/17/23 11:16, Wilco Dijkstra via Libc-alpha wrote:
> So it seems best to state it only works on unsigned values (with y > 0 since division
> by zero is undefined behaviour of course) and it's implementation defined whether
> overflow wraps or saturates.
roundup works just fine on signed integers. Although x should be
nonnegative and y should be positive, there's no requirement that either
x or y must be unsigned.
This sort of thing matters in the C style I prefer nowadays, which is to
use types like ptrdiff_t and idx_t instead of size_t, so that I can
optionally enable runtime overflow checking that works.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: bug in roundup(3) from <sys/param.h>
2023-01-17 20:11 ` Paul Eggert
@ 2023-01-17 20:13 ` Alejandro Colomar
2023-01-17 20:24 ` [RFC] roundup.3: New page documenting roundup(3) (was: bug in roundup(3) from <sys/param.h>) Alejandro Colomar
0 siblings, 1 reply; 7+ messages in thread
From: Alejandro Colomar @ 2023-01-17 20:13 UTC (permalink / raw)
To: Paul Eggert, Wilco Dijkstra, Adhemerval Zanella; +Cc: 'GNU C Library'
[-- Attachment #1.1: Type: text/plain, Size: 961 bytes --]
Hi Paul!
On 1/17/23 21:11, Paul Eggert wrote:
> On 1/17/23 11:16, Wilco Dijkstra via Libc-alpha wrote:
>> So it seems best to state it only works on unsigned values (with y > 0 since
>> division
>> by zero is undefined behaviour of course) and it's implementation defined whether
>> overflow wraps or saturates.
>
> roundup works just fine on signed integers. Although x should be nonnegative and
> y should be positive, there's no requirement that either x or y must be unsigned.
>
> This sort of thing matters in the C style I prefer nowadays, which is to use
> types like ptrdiff_t and idx_t instead of size_t, so that I can optionally
> enable runtime overflow checking that works.
That's fair; I'll clarify, and anyway, will post the manual page for review
before pushing.
If you happen to know od any other use cases for this function, it might be
interesting.
Cheers,
Alex
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [RFC] roundup.3: New page documenting roundup(3) (was: bug in roundup(3) from <sys/param.h>)
2023-01-17 20:13 ` Alejandro Colomar
@ 2023-01-17 20:24 ` Alejandro Colomar
2023-01-17 21:53 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Alejandro Colomar @ 2023-01-17 20:24 UTC (permalink / raw)
To: Paul Eggert, Wilco Dijkstra, Adhemerval Zanella; +Cc: 'GNU C Library'
[-- Attachment #1.1: Type: text/plain, Size: 1212 bytes --]
roundup(3) Library Functions Manual roundup(3)
NAME
roundup - round up in steps
LIBRARY
Standard C library (libc)
SYNOPSIS
#include <sys/param.h>
roundup(x, step);
DESCRIPTION
This macro rounds x to the nearest multiple of step that is not less
than x.
This macro is typically used for rounding up a pointer to align it or
increasing a buffer to be allocated.
This API is not designed to be generic, and doesn’t work in some cases
that are not important for the typical use cases described above. See
CAVEATS.
RETURN VALUE
This macro returns the rounded value.
STANDARDS
This nonstandard macro is present in glibc and some BSDs.
CAVEATS
The arguments may be evaluated more than once.
x should be nonnegative, and step should be positive.
This macro produces incorrect values when x + step would overflow or
wrap around
SEE ALSO
ceil(3), floor(3), lrint(3), rint(3), lround(3), round(3)
Linux man‐pages (unreleased) (date) roundup(3)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] roundup.3: New page documenting roundup(3) (was: bug in roundup(3) from <sys/param.h>)
2023-01-17 20:24 ` [RFC] roundup.3: New page documenting roundup(3) (was: bug in roundup(3) from <sys/param.h>) Alejandro Colomar
@ 2023-01-17 21:53 ` Paul Eggert
2023-01-17 22:29 ` Alejandro Colomar
0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2023-01-17 21:53 UTC (permalink / raw)
To: Alejandro Colomar, Wilco Dijkstra, Adhemerval Zanella
Cc: 'GNU C Library'
On 1/17/23 12:24, Alejandro Colomar wrote:
>
> This macro produces incorrect values when x + step would
> overflow or
> wrap around
The macro can have undefined behavior on overflow, if the result type is
signed. So I suggest replacing "produces incorrect values" with "has
undefined behavior".
I suppose you could also document that the behavior is well-defined if
the result type is unsigned, but that sounds like overkill.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] roundup.3: New page documenting roundup(3) (was: bug in roundup(3) from <sys/param.h>)
2023-01-17 21:53 ` Paul Eggert
@ 2023-01-17 22:29 ` Alejandro Colomar
0 siblings, 0 replies; 7+ messages in thread
From: Alejandro Colomar @ 2023-01-17 22:29 UTC (permalink / raw)
To: Paul Eggert, Wilco Dijkstra, Adhemerval Zanella; +Cc: 'GNU C Library'
[-- Attachment #1.1: Type: text/plain, Size: 1818 bytes --]
Hi Paul,
On 1/17/23 22:53, Paul Eggert wrote:
> On 1/17/23 12:24, Alejandro Colomar wrote:
>>
>> This macro produces incorrect values when x + step would overflow or
>> wrap around
>
> The macro can have undefined behavior on overflow, if the result type is signed.
> So I suggest replacing "produces incorrect values" with "has undefined behavior".
>
> I suppose you could also document that the behavior is well-defined if the
> result type is unsigned, but that sounds like overkill.
Indeed. v2 below.
Cheers,
Alex
---
roundup(3) Library Functions Manual roundup(3)
NAME
roundup - round up in steps
LIBRARY
Standard C library (libc)
SYNOPSIS
#include <sys/param.h>
roundup(x, step);
DESCRIPTION
This macro rounds x to the nearest multiple of step that is not less
than x.
It is typically used for rounding up a pointer to align it or increas‐
ing a buffer to be allocated.
This API is not designed to be generic, and doesn’t work in some cases
that are not important for the typical use cases described above. See
CAVEATS.
RETURN VALUE
This macro returns the rounded value.
STANDARDS
This nonstandard macro is present in glibc and some BSDs.
CAVEATS
The arguments may be evaluated more than once.
x should be nonnegative, and step should be positive.
If x + step would overflow or wrap around, the behavior is undefined.
SEE ALSO
ceil(3), floor(3), lrint(3), rint(3), lround(3), round(3)
Linux man‐pages (unreleased) (date) roundup(3)
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-01-17 22:29 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-17 19:16 bug in roundup(3) from <sys/param.h> Wilco Dijkstra
2023-01-17 19:50 ` Alejandro Colomar
2023-01-17 20:11 ` Paul Eggert
2023-01-17 20:13 ` Alejandro Colomar
2023-01-17 20:24 ` [RFC] roundup.3: New page documenting roundup(3) (was: bug in roundup(3) from <sys/param.h>) Alejandro Colomar
2023-01-17 21:53 ` Paul Eggert
2023-01-17 22:29 ` Alejandro Colomar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).