From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E9D42385840D; Thu, 9 Feb 2023 23:40:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9D42385840D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675986034; bh=iYNhylR7mJ6wxEJTsudjHePUIVbbqGlm4AMUDpAr8Qk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MlabTxOuaG5p9OR74Bz//wnKuv0I8WATZbiOZrOvKn3kldo85Kxbmue1mkJhcS8Se Cmp2PzMwnXnLOlxoRqdhHY21HlCvboQsGQO0bPisc8toJ4lDYCrPHfwbKBRDsAzeLo 361x43JNF3qAgSzTH4hhLSWEH3cMhpYM8iR61xnk= From: "aoliva at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/77760] get_time needs to set tm_wday amd tm_yday Date: Thu, 09 Feb 2023 23:40:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 7.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: aoliva at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D77760 --- Comment #5 from Alexandre Oliva --- I'm not entirely sure what the point of testing for __clang__ is, really. = Is libstdc++ used with, or supposed to be used (say, as a system library) with __clang__? If so, wouldn't it be useful if it actually worked as expected?= =20 Currently, the code compiles just fine, though it fails to parse %I%p if compiled with the actual __clang__ (or when __clang__ is defined on other compilers for whatever reasons, but that's besides the point). My thinking= is that either libstdc++ headers are to work with clang, in which case there's= an error in that bit, or they aren't, in which case the preprocessor test is superfluous and, in this oddball case, harmful. 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 to= day, but when calling the internal implementation primitive do_get, they'd *blin= dly* *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.= =20 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 wors= e, 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 expectation= s.=