Item dates seem to be broken on 32-bit musl 1.2

[nekopsykose]

Newsboat version (copy the output of newsboat -v or the first line of git show):

Newsboat 2.29.0 - https://newsboat.org/
Copyright (C) 2006-2015 Andreas Krennmair
Copyright (C) 2015-2022 Alexander Batischev
Copyright (C) 2006-2017 Newsbeuter contributors
Copyright (C) 2017-2022 Newsboat contributors

Newsboat is free software licensed under the MIT License. (Type `newsboat -vv' to see the full text.)
It bundles:
- JSON for Modern C++ library, licensed under the MIT License: https://github.com/nlohmann/json
- optional-lite library, licensed under the Boost Software License: https://github.com/martinmoene/optional-lite
- expected-lite library, licensed under the Boost Software License: https://github.com/martinmoene/expected-lite

Newsboat 2.29.0
System: Linux 6.0.10-0-xyz (x86_64)
Compiler: g++ 12.2.1 20220924
ncurses: ncurses 6.3.20221126 (compiled with 6.3)
libcurl: libcurl/7.86.0 OpenSSL/3.0.7 zlib/1.2.13 brotli/1.0.9 nghttp2/1.51.0 (compiled with 7.85.0)
SQLite: 3.40.0 (compiled with 3.39.3)
libxml2: compiled with 2.10.2

Config file (copy from ~/.newsboat/config or ~/.config/newsboat/config):
empty

Steps to reproduce the issue:

1. open any feed on a 32-bit musl 1.2 system, idk

Other info you think is relevant:

on a 64-bit system, with https://social.treehouse.systems/@marcan.rss as the sole url in ~/.newsboat/urls:

Newsboat 2.29.0 - Articles in feed 'Hector Martin' (20 unread, 20 total) - https://social.treehouse.systems/@marcan.rss
   1 N  Dec 03   203   109447971687181420
   2 N  Dec 02   213   109441875890551358
   3 N  Dec 02   671   109441870318393322
   4 N  Nov 28   196   109420862652320078
   5 N  Nov 28   762   109420859349587697
   6 N  Nov 26   513   109408192786292944
   7 N  Nov 26    58   109408013385376758
   8 N  Nov 22   248   109387939953882850
   9 N  Nov 22   343   109386987351333117
  10 N  Nov 22   1.1K  109386654184095095
  11 N  Nov 21   163   109382184123846257
  12 N  Nov 20    36   109376434341919332
  13 N  Nov 20   319   109374672766433721
  14 N  Nov 20   210   109374666547170531
  15 N  Nov 20    54   109373692359879200
  16 N  Nov 19   242   109369145771646198
  17 N  Nov 17   272   109359975139353020
  18 N  Nov 17   439   109359926470501861
  19 N  Nov 17   218   109359914213636319
  20 N  Nov 17   309   109359331538695321

the same thing on a 32-bit system (specifically, an armv7 userspace container running on aarch64 hardware):

Newsboat 2.29.0 - Articles in feed 'Hector Martin' (17 unread, 20 total) - https://social.treehouse.systems/@marcan.rss
   1 N  May 29   343   109386987351333117
   2 N  May 29    58   109408013385376758
   3 N  May 28   1.1K  109386654184095095
   4 N  May 27   218   109359914213636319
   5 N  May 27    54   109373692359879200
   6 N  May 27   163   109382184123846257
   7 N  May 27    36   109376434341919332
   8 N  May 27   319   109374672766433721
   9 N  May 27   272   109359975139353020
  10 N  May 27   203   109447971687181420
  11 N  May 27   671   109441870318393322
  12 N  May 26   309   109359331538695321
  13 N  May 26   248   109387939953882850
  14 N  May 26   513   109408192786292944
  15 N  May 26   762   109420859349587697
  16 N  May 25   196   109420862652320078
  17 N  May 25   439   109359926470501861
  18 N  May 25   213   109441875890551358
  19 N  May 25   242   109369145771646198
  20 N  May 25   210   109374666547170531

(also note the 'marker' at the 1.1K size and how offset it is- it's a different resulting order for the same request at the same time, on top of all the dates being wrong. those are the same responses where the sizes match).

(it also then segfaults on exit, but i can't debug that in a container without ptrace. probably caused by the same issue anyway.).

this is probably related to the 64-bit-always time_t change in musl 1.2 if i had to guess and some type via the libc crate messing it up, as the rust libc::time_t type is c_long which is 32-bit for musl (for which the fix is in rust-lang/libc#2088 i guess, but not sure if it might be something else entirely).

[Minoru]

Thanks for the report, and sorry for such a late response!

Dates are parsed with RssParser::w3cdtf_to_rfc822() (rss/rssparser.cpp), which doesn't involve Rust or libc crate. Probably just an error in our own parsing logic.

Haven't tried to reproduce this yet. I guess the first step would be to grab the feed from that URL, put it into tests/data and write a test for the parser to check which dates it returns; then upgrading to musl 1.2 and ensuring it still passes; then checking that the fixes didn't break musl pre-1.2 and other libcs.

[nekopsykose]

Dates are parsed with RssParser::w3cdtf_to_rfc822() (rss/rssparser.cpp), which doesn't involve Rust or libc crate.

ah! my apologies, i see rust somewhere and always jump to that as the first conclusion without checking further. i guess that (somewhat) simplifies the fixability.

sorry for such a late response!

no worries. no priority from me- someone had just noticed it on IRC and i reproduced it for them and though i'd write it out here just to make sure it was known and not invisible. i don't have any 32-bit systems myself.