Re: strftime(3) oddities with %s, %z

[Steffen Nurpmeso <steffen%sdaoden.eu@localhost>]

Mouse wrote in
 <202211021508.LAA26854%Stone.Rodents-Montreal.ORG@localhost>:
 |> Suppose you create a struct tm _without_ gmtime(3) or localtime(3),
 |> using designated initializers or memset for zero-initialization, with
 |> only what is included in POSIX:
 |
 |> struct tm tm = {
 |>  .tm_sec = 56,
 |>  .tm_min = 34,
 |>  .tm_hour = 12,
 |>  .tm_mday = 1,
 |>  .tm_mon = 12 - 1,  /* December */
 |>  .tm_year = 2021 - 1900,
 |>  .tm_wday = 3,              /* Wednesday */
 |>  .tm_yday = 334,            /* zero-based day of year (%j - 1) */
 |>  .tm_isdst = 0,
 |>};
 |
 |This is fine.  But using memset is not; if struct tm contains a pointer
 |or a floating-point value, setting it to all-0-bits may produce a trap
 |representation - or, possibly worse, a valid value that means something
 |different from what you intend.
 |
 |Unless POSIX was stupid enough to mandate that all-bits-0 is nil for
 |any pointer type and something well-defined for floating-point.  (I'd

The former is definetely true.  (Or will be.)
And i think on the TZ list it just came up it is generally true
for all "modern" machines.  (Except for C++ member pointers which
may be -1 (in parts, i hated their double-pointer size).)

 |be surprised by that, but standards bodies have surprised me often
 |enough in the past.)  Certainly C doesn't, at least not as of C99 - I
 |don't have a copy of anything newer.

Ah.  ISO C.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)