Hello Jeremie,
Sorry for the late reply.
On 08/05/2019 16:30, Jeremie Courreges-Anglas wrote:
> On Wed, May 08 2019, Jeremie Courreges-Anglas <jca@wxcvbn.org> wrote:
>> On Mon, May 06 2019, Jeremie Courreges-Anglas <jca@wxcvbn.org> wrote:
>>
>> [...]
>>
>>> One serious issue, straight from the 80's, is the lack of feature
>>> detection for lots of stuff, leading to ugly #ifdefs. For example,
>>> using gcc -std=gnu89, the only warning you get is:
>>>
>>> timing.c:103: warning: passing argument 1 of 'time' from incompatible pointer type
>>>
>>> The code passes a "long" instead of a "time_t" to time(3). If you look
>>> at timing.c you see that time(3) is used as a fallback when neither
>>> clock(3), times(2) or getrusage(2) are available. But to unveil the
>>> better code, you need to add the appropriate -DHAVE_CLOCK to CPPFLAGS;
>>> see base/config.h for more fun. It's a shame for a project using
>>> autoconf-2.69.
>>
>> Here's a minimal diff to work around the time_t issue - a potential
>> stack overflow on 32 bits archs - by using what should be a better code
>> path. time(3) counts real seconds, not consumed cpu time.
>>
>> Note that the time_t issue is still a bug on all 32 bits archs using
>> a 64 bits time_t. To fix it, the type of variables "st" and "now"
>> in base/timing.c should be changed from "long" to "time_t".
>>
>> ok?
>
> Err, newer patch with a comment explaining the rationale.
>
> ok?
Probably I'm not the right person to give an "Ok", but I confirm that no
unexpected behaviours happen after installing the patch (tested on amd64
only).
All the best
--
Alessandro DE LAURENZIS
[mailto:just22@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: https://www.linkedin.com/in/delaurenzis/
No comments:
Post a Comment