On 12.12.2018 23:06, Warner Losh wrote: > > > On Wed, Dec 12, 2018 at 2:34 PM Joerg Sonnenberger <joerg%bec.de@localhost > <mailto:joerg%bec.de@localhost>> wrote: > > On Wed, Dec 12, 2018 at 08:46:33PM +0100, Michał Górny wrote: > > While researching libc++ test failures, I've discovered that NetBSD > > suffers from the same issue as FreeBSD -- that is, both the userspace > > tooling and the kernel have problems with (time_t)-1 timestamp, > > i.e. one second before the epoch. > > I see no reason why that should be valid or more general, why any > negative value of time_t is required to be valid. > > > Does (time_t)-1 mean a date in 1969 (int)? Or does it mean a date in > 2106 (uint32_t)? Or is it a date in 584942419325 (uint64_t)? I don't > think that POSIX actually says anything about the right answer. All I > could find about what time_t is the vague statement: "time_t Used for > time in seconds." and the following from the time() call: 'Upon > successful completion, /time/() shall return the value of time. > Otherwise, (time_t)-1 shall be returned.' This strongly implies, to my > mind, that -1 is not a valid time_t. > > Warner > As mentioned earlier, signedness of time_t is not mandated according to C and POSIX. The current consensus is to keep it as signed and gain additional extended range of values with the switch to 64-bit format. By the spirit of recent standard, it's in my opinion possible to defend that time_t is more natural to be signed. There are POSIX interfaces that assume time prior UNIX epoch like struct tm (tm_year - years since 1900.. n.b. they can be negative too). getdate() is expected to fail if the time cannot be represented as time_t, and for dates prior UNIX epoch you need negative time_t. 64-bit integer type is used in rationale for current development of the interfaces. Negative time is not that alien concept in the standard, as there are mentions about positive and negative leap seconds that must be supported. On 13.12.2018 08:16, Michael van Elst wrote: > n54%gmx.com@localhost (Kamil Rytarowski) writes: > >> I disagree, this used to be a flaw in C/POSIX interface to keep one >> specific point of time invalid. It should be fixed similarly to other OSe= >> s. > > negative time_t values don't specify a point in time. The talk about > "one specific point of time invalid" is nonsense. > The current custom is that negative time_t does specify a point of time prior UNIX epoch.. (time_t)-1 is a specific date in 1969. 1969 existed for me. On 12.12.2018 23:06, Warner Losh wrote: > Otherwise, (time_t)-1 shall be returned.' This strongly implies, to my > mind, that -1 is not a valid time_t. This does not imply that -1 is invalid only. There are interfaces with a similar flaw (standard ones like strtol(3), extension ones like ptrace(2)). In these cases there is need to check errno to catch errors.
Attachment:
signature.asc
Description: OpenPGP digital signature