Since October 2018 building notmuch has actually required compiler
that knows C11.
Also this -std=gnu99 was not used in code compiled by configure,
so in theory this could have caused problems...
...but no related reports have been sent, perhaps ever.
Both gcc and clang has been shipping
On Wed, Jun 24 2020, David Bremner wrote:
> Certain tests involving timestamps > 32bits cannot pass with the
> current libnotmuch API. We will avoid this isssue for now by disabling
s/isssue/issue/
> those tests on "old" architectures with 32bit time_t.
> ---
> configure | 33
I haven't traced the code path as exhaustively for the SMIME test, but
the expiry date in question is larger then representable in a signed
32 bit integer.
---
test/T160-json.sh | 3 +++
test/T355-smime.sh | 3 +++
2 files changed, 6 insertions(+)
diff --git a/test/T160-json.sh
Certain tests involving timestamps > 32bits cannot pass with the
current libnotmuch API. We will avoid this isssue for now by disabling
those tests on "old" architectures with 32bit time_t.
---
configure | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff
David Bremner writes:
>
> This is not a complete fix, but at least the timestamp ends up
> aparently correct in the database. It looks like there are still
> wonky conversions on reading the large timestamp from the database.
There is another cast that is harder to avoid:
On Mon, 22 Jun 2020 12:22:50 +0200 Lukasz Stelmach
wrote:
> It was <2020-06-20 sob 12:53>, when Reto wrote:
> > On Fri, Jun 19, 2020 at 12:40:49PM +0200, Ćukasz Stelmach wrote:
> >> Having "setup" in the set requires entering three instad of two characters
> >> for "search". Since "setup" is