Change Details

This should be pretty easy but there's no real payoff and no likely risk of keeping the current behavior. So save it for if we need a break and want to work on something silly. As of commit 18a93372, we can use the `%j` `printf()` specifier for `(u)intmax_t`. That commit is how I learned that `intmax_t` exists, and to be honest I was just trying to think of a use case. `intmax_t` refers to the largest signed integer type supported by the implementation. Currently, we cast `time_t` values to `long long` for the `printf()` family of functions. The C standard allows `time_t` to be any numeric type; the POSIX standard allows `time_t` to be any integer type; and glibc allows `time_t` to be any **signed** integer type. Note that FreeBSD doesn't use glibc, but for our purposes it shouldn't matter if we assume it's signed. Even if it is signed, **technically** it could be bigger than `long long`. We could also have a `pcmk__xml_add_time_t()` equivalent of `crm_xml_add_ll()` for convenience, to do the casting. Note: Someone (linked below) is especially passionate that `intmax_t` is no good. I have barely skimmed this article. https://thephd.dev/intmax_t-hell-c++-c --- Similarly: * `uintmax_t` for `rlim_t` (currently in `remove_core_file_limit()`) * `intmax_t` for `pid_t` * `intmax_t` for `uid_t` and `gid_t` (these may be either signed or unsigned integer types, and determining which one isn't worth the autoconf trouble)

This should be pretty easy but there's no real payoff and no likely risk of keeping the current behavior. So save it for if we need a break and want to work on something silly. As of commit 18a93372, we can use the `'j'` `printf()` modifier for `(u)intmax_t`. That commit is how I learned that `intmax_t` exists, and to be honest I was just trying to think of a use case. `intmax_t` refers to the largest signed integer type supported by the implementation. Currently, we cast `time_t` values to `long long` for the `printf()` family of functions. The C standard allows `time_t` to be any numeric type; the POSIX standard allows `time_t` to be any integer type; and glibc allows `time_t` to be any **signed** integer type. Note that FreeBSD doesn't use glibc, but for our purposes it shouldn't matter if we assume it's signed. Even if it is signed, **technically** it could be bigger than `long long`. We could also have a `pcmk__xml_add_time_t()` equivalent of `crm_xml_add_ll()` for convenience, to do the casting. Note: Someone (linked below) is especially passionate that `intmax_t` is no good. I have barely skimmed this article. https://thephd.dev/intmax_t-hell-c++-c --- Similarly: * `uintmax_t` for `rlim_t` (currently in `remove_core_file_limit()`) * `intmax_t` for `pid_t` * `intmax_t` for `uid_t` and `gid_t` (these may be either signed or unsigned integer types, and determining which one isn't worth the autoconf trouble)

This should be pretty easy but there's no real payoff and no likely risk of keeping the current behavior. So save it for if we need a break and want to work on something silly. As of commit 18a93372, we can use the `%j`'j'` `printf()` specmodifier for `(u)intmax_t`. That commit is how I learned that `intmax_t` exists, and to be honest I was just trying to think of a use case. `intmax_t` refers to the largest signed integer type supported by the implementation. Currently, we cast `time_t` values to `long long` for the `printf()` family of functions. The C standard allows `time_t` to be any numeric type; the POSIX standard allows `time_t` to be any integer type; and glibc allows `time_t` to be any **signed** integer type. Note that FreeBSD doesn't use glibc, but for our purposes it shouldn't matter if we assume it's signed. Even if it is signed, **technically** it could be bigger than `long long`. We could also have a `pcmk__xml_add_time_t()` equivalent of `crm_xml_add_ll()` for convenience, to do the casting. Note: Someone (linked below) is especially passionate that `intmax_t` is no good. I have barely skimmed this article. https://thephd.dev/intmax_t-hell-c++-c --- Similarly: * `uintmax_t` for `rlim_t` (currently in `remove_core_file_limit()`) * `intmax_t` for `pid_t` * `intmax_t` for `uid_t` and `gid_t` (these may be either signed or unsigned integer types, and determining which one isn't worth the autoconf trouble)