Re: [exim-dev] test suite - new quota error

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Phil Pennock
Datum:  
To: John Jetmore
CC: exim-dev
Betreff: Re: [exim-dev] test suite - new quota error
On 2010-06-12 at 09:46 -0400, John Jetmore wrote:
> I'm really confused by this. I've done some more looking, I'm hoping
> you'll look at what I've found and that will lead closer to the heart
> of the problem.


Problem identified and I believe resolved. Please cvs up and try again?

> First Failure:
> Exim version 4.72 #1 built 07-Jun-2010 21:47:01
> Size of off_t: 28752091627388932


Okay, so if sizeof() yields 4-byte results and we parse 8 bytes of
memory for an integer to print, I could see that happening.

> Now, I'm still not exactly sure why that relates to the quota stuff
> (as you said, it's doing direct sizeof() tests), but it does appear


The good news: the quota stuff is unaffected and has not been broken.
Okay, less confusion on my part now.

Exim always panics if you set a quota larger than it can handle on a
32-bit off_t; if you want more, use a 64-bit system. The only change
here is that the test suite avoids even invoking the >2G test unless
{ exim -bV } suggests it's possible.

5000-maildir/5007 uses "need_largefiles", which means the test is only
run if "runtests" has $have_largefiles set, which it does if the -bV
line's number is more than 4.

So, no mystery on why the quota stuff is broken. :)

Request: have the tests fail if -bV exports a number larger than 32. :)

> that the SIZE_T_FMT stuff you added somehow broke the -bV output. On
> my test system, building from HEAD, here are the FMT's that are built
> into config.h by buildconfig.c:


>     #if __STDC_VERSION__ >= 199901L
>     fprintf(new, "#define SIZE_T_FMT  \"%%zu\"\n");
>     #else
>     # ifdef PRIdMAX
>     fprintf(new, "#define SIZE_T_FMT  \"%%" PRIdMAX "\"\n");
>     # else
>     if (sizeof(test_size_t) > sizeof (test_ulong_t))
>       fprintf(new, "#define SIZE_T_FMT  \"%%llu\"\n");
>     else
>       fprintf(new, "#define SIZE_T_FMT  \"%%lu\"\n");
>     # endif
>     #endif

>
> I think by process of elimination that means that lld is coming from
> PRIdMAX (and the quick test I wrote confirms that PRIdMAX is lld).
>
> So, I'm still not sure what's going on here, but could you revisit
> your logic for building SIZE_T_FMT?


Okay, I've just convinced myself that assuming that size_t will be as
large as the maximum integer type is broken; it fails on systems with
64-bit int support but only 32-bit addressability. Ugh. Stupid
optimisation of logic on my part.

I've removed the PRIdMAX #ifdef branch (and the <inttypes.h> inclusion).

If things work for you now, then I think we're good. Sorry for the
broken code.

-Phil