You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @HowardHinnant, I received this report from a user who couldn't compile date through clock r-lib/clock#234. It looks to be the same as #264.
I was looking at your suggested fix here #264 (comment), and was wondering if patching that line in the copy of date that I ship is still the correct thing to do? i.e. is that patch up to date or should there be different defaults now?
Is there any way this could be patched in date itself?
Finally, do you think that adding CONSTDATA weekday nanwd{8u}; like nanyear, and then using that as the default value of wd in struct fields would also "fix" it?
Hi @HowardHinnant, I received this report from a user who couldn't compile date through clock
r-lib/clock#234. It looks to be the same as #264.
I was looking at your suggested fix here #264 (comment), and was wondering if patching that line in the copy of date that I ship is still the correct thing to do? i.e. is that patch up to date or should there be different defaults now?
Here are the relevant lines in date.h as of now:
https://github.com/r-lib/tzdb/blob/bf6c79a0f53f39e4eedbef951af0fe4e1335a4c5/inst/include/date/date.h#L4798-L4808
Is there any way this could be patched in date itself?
Finally, do you think that adding
CONSTDATA weekday nanwd{8u};
likenanyear
, and then using that as the default value ofwd
instruct fields
would also "fix" it?I believe I also found the specific bug report to gcc here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930
Thanks!
The text was updated successfully, but these errors were encountered: