Groups | Search | Server Info | Login | Register
Groups > comp.lang.c > #396726
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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