Re: [exim-dev] [exim-cvs] Compiler quietening

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: exim-dev
Subject: Re: [exim-dev] [exim-cvs] Compiler quietening
On 2014-06-04 at 20:17 +0100, Exim Git Commits Mailing List wrote:
> Gitweb:     http://git.exim.org/exim.git/commitdiff/35b7b6ff525028eef69cf19d86f77deb1a84b7c9

>
>     Compiler quietening


(stripping Author, as irrelevant to this, which is about a broader
issue).

>      /* build unique id for MIME boundary */
> -    snprintf(boundaryStr, 63, "%d-eximdsn-%d", time(NULL), rand());      
> +    snprintf(boundaryStr, 63, "%l-eximdsn-%d", (long) time(NULL), rand());      
>      DEBUG(D_deliver) debug_printf("DSN: MIME boundary: %s\n", boundaryStr);


Do we care that we're making life harder for Cygwin folks here?

I can never remember which architectures make which size trade-offs, so
resort to wikipedia for a table:
http://en.wikipedia.org/wiki/64-bit_computing
which says that IL32P64 is only really Windows.

Windows has time32() and time64() apparently, but I'm not seeing which
is used under Cygwin in a miniscule amount of searching. (And I don't
remember which platform it is which makes time_t be floating point, but
note that this is clearly allowed under standards).

Looking, we appear to be a complete mess of using time_t, unsigned int,
long int and plain int (deliver_frozen_at, for instance) for storing the
result of a call to time(NULL). This is disconcerting.

I think though that since we have format string detection in
buildconfig.c, we should be using the results of that and using
TIME_T_FMT instead of "%d". It's only currently used in prvs_daystamp()
but _is_ being used, non-optionally compiled, so should be working on
all platforms. It becomes either "%lld" or "%ld", depending upon the
platform.

-Phil
--
My employer, Apcera Inc, is hiring sysadmin; primarily San Francisco:
http://www.apcera.com/jobs/#operations-engineer
(but all the mistakes in this email are made in my personal capacity)