| Summary: | RLIM_INFINITY definition is apparently wrong | ||
|---|---|---|---|
| Product: | Base System | Reporter: | jau |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
jau
2000-10-13 07:30:00 UTC
On Thu, 12 Oct 2000 jau@iki.fi wrote: > >Description: > RLIM_INFINITY is currently defined as follows... > > #define RLIM_INFINITY ((rlim_t)(((u_quad_t)1 << 63) - 1)) > > This is apparently wrong, because using an unsigned quad length > integer to represent the value hints that the intended bit pattern > to represent infinity is all 64 bits one, 0xFFFFFFFFFFFFFFFF. > The current definition makes the pattern anyhow 0x3FFFFFFFFFFFFFFF, > which does not require an unsigned type at all. Actually, the current definition makes the bit pattern 0x7FFFFFFFFFFFFFFF. This doesn't require an unsigned type, but one more than it does (on most machines), since subtracting one from the value with bit pattern 0x8000000000000000 would overflow on most machines. Bruce State Changed From-To: open->feedback What was the conclusion here? Is this a bug or not? State Changed From-To: feedback->closed The submitter agrees that due to the current type of rlim_t (quad_t), the present value of RLIM_INFINITY is reasonable (it is defined as 0x7fffffffffffffff, the largest value representable by the type). |