On Fri, Jun 07 2019, Alessandro DE LAURENZIS <jus...@atlantide.t28.net> wrote: > 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 <j...@wxcvbn.org> wrote: >>> On Mon, May 06 2019, Jeremie Courreges-Anglas <j...@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",
Actually I usually ask for oks from maintainers, even when they don't have a cvs account. This whole "contributor or maintainer or developer" scheme can be confusing sometimes. > but I confirm that no > unexpected behaviours happen after installing the patch (tested on amd64 > only). Thanks, committed. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
