https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Alexandre Oliva from comment #5) > As for tm bits, my suggestion was to overwrite tm fields internally, not to > expose that externally. They'd be used as scratch bits. As in, member > functions in the public interface would not use incoming tm bits as > __time_get_state, but rather a zeroed-out __time_get_state structure, as > today, but when calling the internal implementation primitive do_get, they'd > *blindly* *overwrite* some of the tm bits with those from __time_get_state, > and when do-get returns, they'd pull them back into __time_get_state and out > of tm. They'd be used as scratch bits, which AFAICT is permissible. > do_get, being protected and thus more of an internal implementation bit, > could make use of those scratch bits. do_get overriders could tweak them, > for better or worse, but since this use would be nonstandard, we could > probably get away with assuming any such uses to be libstdc++-specific. It > would probably not be wise for users to rely on this internal extension, > though, since one can hope the standard will eventually make room for an > implementation of time_get that is both standard-compliant and compatible > with reasonable strptime expectations. If all users would initialize struct tm to zeros before calling the APIs, then I can understand that it would work (but still libstdc++ would need to know which of the calls are nested and which are the outermost, so that they'd finalize the state before leaving the outermost method back to canonical form). But if some fields can be uninitialized, I really don't understand how you could use them as scratch bits, they could have random values upon entering the outermost method. I don't know if C++ says anything about the prior content of struct tm (but given the recursive processing of some format specifiers it is hard to imagine they'd e.g. clear the whole struct), for strptime POSIX manpage says: "It is unspecified whether multiple calls to strptime() using the same tm structure will update the current contents of the structure or overwrite all contents of the structure. Conforming applications should make a single call to strptime() with a format and all data needed to completely specify the date and time being converted." and the Linux manpage: "In principle, this function does not initialize tm but stores only the values specified. This means that tm should be initialized before the call. Details differ a bit between different UNIX systems. The glibc implementation does not touch those fields which are not explicitly specified, except that it recomputes the tm_wday and tm_yday field if any of the year, month, or day elements changed." Now, if even the POSIX manpage shows in an example a case where struct tm isn't zeroed out before calling it (but has format specifiers to initialize everything).
