Groups | Search | Server Info | Login | Register


Groups > comp.lang.c > #396726

Re: printf and time_t

From Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups comp.lang.c
Subject Re: printf and time_t
Date 2026-03-02 03:37 -0800
Organization None to speak of
Message-ID <87tsuysbrh.fsf@example.invalid> (permalink)
References (1 earlier) <10jfs23$2liif$1@dont-email.me> <10jgc2t$2rp4s$2@nntp.eternal-september.org> <86o6n5pocw.fsf@linuxsc.com> <10jm6se$r6nl$1@dont-email.me> <864imyg0im.fsf@linuxsc.com>

Show all headers | View raw


Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> writes:
>> On 2026-01-07 08:02, Tim Rentsch wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>> On 2026-01-05 03:17, Andrey Tarasevich wrote:
>>>>> You can't.  As far as the language is concerned, `time_t` is intended
>>>>> to be an opaque type.  It has to be a real type, ...
>>>>
>>>> In C99, it was only required to be an arithmetic type.  I pointed out
>>>> that this would permit it to be, for example, double _Imaginary.  [...]
>>>
>>> It's hard to imagine how time_t being an imaginary type could
>>> provide the semantics described in the C standard for time_t.
>>
>> You'll need to elaborate on that.  time_t is an opaque type which
>> could, on one implementation, have been long double.  Another
>> implementation could have stored the same value as the imaginary
>> component of _Imaginary long double, and could work with that value
>> the same way as the first one. [...]
>
> The C standard doesn't say that time_t is an opaque type.

Nor does it say that it isn't.  The C standard does not define or use
the word "opaque".  I'm not sure I would have said that time_t is an
"opaque type", but the usage doesn't seem entirely unreasonable.

Informally, it's usually best to *treat* time_t as opaque (much
like type FILE can informally be considered opaque, more so than
time_t), dealing with it only via functions declared in <time.h>.
You can apply arithmetic operations to values of type time_t, but
the results are not necessarily meaningful.  (And of course you
can write code whose behavior depends on how time_t is defined,
which makes it, I suppose, not entirely opaque.)

[...]

> Besides all of that, _Imaginary types don't satisify the condition
> for time_t to be an arithmetic type.  Annex G says the imaginary
> types are floating types, but in C99 Annex G is informative, not
> normative.

In a C99 implementation that supports imaginary types in accordance
with Annex G, they are arithmetic types, and therefore candidates
for the underlying type of time_t.  (Making time_t imaginary would
be silly but conforming.)

(In C11 and later, Annex G is normative.  The main difference is that
a C11 or later implementation that defines __STDC_IEC_559_COMPLEX__
"shall", rather than "should", conform to the specifications to
the annex.  C23 changes the macro to __STDC_IEC_60559_COMPLEX__
and makes __STDC_IEC_559_COMPLEX__ obsolescent.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 05:02 -0800
  Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-07 12:58 -0500
    Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 23:21 -0800
      Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-02 03:37 -0800
      Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-02 17:53 -0500
        Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-02 18:04 -0800

csiph-web