Bug 221418
| Summary: | FreeBSD 10.4-PRERELEASE fails to build on systems using 32 bit time_t since r322315. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | jau | ||||
| Component: | kern | Assignee: | Michael Tuexen <tuexen> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | cem, emaste, tuexen | ||||
| Priority: | --- | Keywords: | patch | ||||
| Version: | 10.3-STABLE | Flags: | koobs:
mfc-stable10+
|
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Truncated INT64_MIN should be INT32_MIN on 2's complement, not 0. Seems like we just lack a (time_t) cast on the value. With regards to your patch, CHAR_BIT is always 8 on FreeBSD. It should already be fixed by https://svnweb.freebsd.org/changeset/base/322454 To Conrad I have to point out that truncating INT64_MIN to 32 bits might produce INT32_MIN on a big endian system. On a little endian platform the type cast invariably produces a plain zero (0). Concerning my using CHAR_BIT instead of plain numeric 8 I have to say I like portability enough to assume someone some day might wish to use FreeBSD on a system which does not use the 8/16/32/64 bits basic data units division our contemporary systems use. Maybe one day there is a reason to run FreeBSD on a system using 9/18/36 data unit division like in the old PDP-10 or IBM 7094. When there is no real reason to use minimum time_t it is in my opinion really much better to use -(SYNCOOKIE_LIFETIME + 1) as done in the fix 322454. Thanks Michael! Assign to committer that resolved, track MFH |
Created attachment 185286 [details] Assign the correct time_t value on any system using 2's complement integers independent of the size of time_t. FreeBSD 10.4-PRERELEASE fails to build on systems using 32 bit time_t since r322315. In the file sys/netinet/tcp_syncache.c line 280 reads like this... V_tcp_syncache.hashbase[i].sch_last_overflow = INT64_MIN; This works as intended only on systems using 64 bit time_t. The target variable for the assignment is of type time_t and the assigned value overflows the range of the target. If the assignment were done the assigned value would be cut to 0. At least on ppc systems the old gcc detects this, gives an error message, and the build fails to proceed.