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
