On 24/11/17 00:31, Paul Eggert wrote:
> Pádraig Brady wrote:
>> It's not introducing any new issue I think, but
>> seems to be triggering the compiler warning due
>> to tm_year being explicitly set?
>
> Actually, I think it's pointing out an issue with the API. If the caller to
> posixtime were t
Pádraig Brady wrote:
It's not introducing any new issue I think, but
seems to be triggering the compiler warning due
to tm_year being explicitly set?
Actually, I think it's pointing out an issue with the API. If the caller to
posixtime were to specify neither PDS_LEADING_YEAR nor PDS_TRAILING_
On 25/09/17 18:29, Paul Eggert wrote:
> * lib/parse-datetime.y (parse_datetime2):
> * lib/posixtm.c (posixtime):
> Do not access uninitialized storage, even though the resulting
> value is never used.
> ---
> ChangeLog| 8
> lib/parse-datetime.y | 16 ++--
> lib/p
Thien-Thi Nguyen wrote:
Maybe add a preemptive
comment, or factor the assignments into a macro (w/ comment)?
It's not worth a macro. Feel free to add a comment.
() Paul Eggert
() Mon, 25 Sep 2017 18:29:08 -0700
Do not access uninitialized storage, even though the
resulting value is never used.
[...]
- tm0 = tm;
+ tm0.tm_sec = tm.tm_sec;
+ tm0.tm_min = tm.tm_min;
+ tm0.tm_hour = tm.tm_hour;
+ tm0.tm_mday
* lib/parse-datetime.y (parse_datetime2):
* lib/posixtm.c (posixtime):
Do not access uninitialized storage, even though the resulting
value is never used.
---
ChangeLog| 8
lib/parse-datetime.y | 16 ++--
lib/posixtm.c| 7 ++-
3 files changed, 28 inse
