Re: mountlist: support windows

2018-10-10 Thread Bruno Haible
Hi Assaf, > Attached 2 patches: > >mountlist tests: add mountlist-tests module >mountlist: add support for windows DOS-style drives Two great contributions!! Comments about 0001-mountlist-tests-add-mountlist-tests-module.patch: It's your first gnulib test. I appreciate it! In the inc

Re: memory leaks in gnulib tests (for ASAN/LINT)

2018-10-10 Thread Paul Eggert
On 10/10/18 7:05 AM, Tim Rühsen wrote: Given Paul's statement "Besides, debugging tools come and go...": this means with 100 such tools we (or the people who care) would need to write and maintain 100 exception files. Exception files are not the only way to suppress false positives. It would

Re: bug#6816: df bug on 64-bit Solaris (need to use getextmntent)

2018-10-10 Thread Bruno Haible
Hi Assaf, > In 2014 gnulib gained the following commit: > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=502809019bd2ca3ce3d041d18c35ce9420eedb72 > === > commit 502809019bd2ca3ce3d041d18c35ce9420eedb72 > Author: Ben Walton > Date: Tue Jun 3 23:01:14 2014 +0100 > > mountlist: avoi

Re: memory leaks in gnulib tests (for ASAN/LINT)

2018-10-10 Thread Bruno Haible
Hi Assaf, > In this specific case, the fix is rather simple and costs very little. > would you consider it? Yes. But I don't like the '#ifdef lint' lines. Unit tests are not optimized for speed. Instead, I find it useful to not multiply the number of possible configurations of the tests (with an

Re: memory leaks in gnulib tests (for ASAN/LINT)

2018-10-10 Thread Assaf Gordon
Hello all, You raise many good points, both for and against. In this specific case, the fix is rather simple and costs very little. would you consider it? With it, sed and sed's gnulib testsuite passes all tests under SASN, which is a nice bonus (and will also prevent false reports in the futur

mountlist: support windows

2018-10-10 Thread Assaf Gordon
Hello, Attached 2 patches: mountlist tests: add mountlist-tests module mountlist: add support for windows DOS-style drives The second patch enables the completion of coreutils' "./configure" under windows with mingw compiler (not the entire build, just "configure") instead of failing with:

Re: timevar: further work

2018-10-10 Thread Bruno Haible
Hi Akim, > The choice between proper time and self+children > seems a reasonable option to offer, but if we are to keep just one, > I’d stick with the one we have currently: including subprocesses. OK. > > So, very obviously, the resolution of times() is [10] milliseconds (!). > […] > > So, the

Re: timevar: further work

2018-10-10 Thread Akim Demaille
Hey! > Le 10 oct. 2018 à 10:10, Bruno Haible a écrit : > > Hi Akim, > >> With respect to precision: > >> - times returns a clock_t, in system dependent clock ticks. >>Resolution is unclear, but I think I understood from various >>place that it’s typically 1µs. > > No, you can't assum

Re: bug#6816: df bug on 64-bit Solaris (need to use getextmntent)

2018-10-10 Thread Assaf Gordon
(triaging old bugs) Hello, On 15/09/10 04:18 PM, Eric Blake wrote: On 08/06/2010 01:56 PM, Wood, David wrote: From mnttab(4) on Solaris 10: [...] At this point, me->me_dev contains a wrongly packed (32-bit) device number, which forces the find_mount_point() code path (causing other unpl

Re: memory leaks in gnulib tests (for ASAN/LINT)

2018-10-10 Thread Bruno Haible
Hi Tim, There is no way to avoid not-serious memory leaks in the long run. 1) There are API functions like bindtextdomain(), textdomain() which are supposed to keep information until the process terminates. 2) There are certain tasks like reading an initialization file (think of ~/.w

Re: memory leaks in gnulib tests (for ASAN/LINT)

2018-10-10 Thread Tim Rühsen
On 10/10/18 11:10 AM, Bernhard Voelker wrote: > On 10/9/18 7:37 PM, Paul Eggert wrote: >> If we want to silence these diagnostics we can either complicate the source >> code or complicate the debugging tool. > > I'm fine with either. Myy only concern is that code from the gnulib tests > might >

Re: memory leaks in gnulib tests (for ASAN/LINT)

2018-10-10 Thread Bernhard Voelker
On 10/9/18 7:37 PM, Paul Eggert wrote: > If we want to silence these diagnostics we can either complicate the source > code or complicate the debugging tool. I'm fine with either. Myy only concern is that code from the gnulib tests might be taken as basis for application code. Still, it's the r

Re: timevar: further work

2018-10-10 Thread Bruno Haible
> So, very obviously, the resolution of times() is 20 milliseconds (!). Oops. It is 10 milliseconds, not 20 milliseconds. But that does not change the conclusion. Bruno

Re: timevar: further work

2018-10-10 Thread Bruno Haible
Hi Akim, > With respect to wall clock: > > - nothing in getrusage. You suggest gettimeofday, but it’s > not monotonic, clock_gettime(CLOCK_MONOTONIC,…) is a better > option. OK, point taken. > With respect to precision: > - times returns a clock_t, in system dependent clock ticks.

Re: timevar: further work

2018-10-10 Thread Akim Demaille
> Le 10 oct. 2018 à 07:29, Akim Demaille a écrit : > > It seems that both choices are fairly equivalent. That’s what I > can see looking at macOS and GNU/Linux. I have no idea about the > other platforms. I should have stated that getrusage is more than just clocks: it gives measures about