pcp
[Top] [All Lists]

Re: [pcp] qa failures on 32-bit debian 7.4

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] qa failures on 32-bit debian 7.4
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 13 Oct 2015 18:54:07 -0400 (EDT)
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <561D58FD.20707@xxxxxxxxxxxxxxxx>
References: <56172CF1.3020100@xxxxxxxxxxxxxxxx> <435671960.51650257.1444365661548.JavaMail.zimbra@xxxxxxxxxx> <561C2DBA.4090403@xxxxxxxxxxxxxxxx> <1371885424.53513917.1444699604704.JavaMail.zimbra@xxxxxxxxxx> <561D58FD.20707@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: DVIgaFcLGXffjwMYU1aakTdUmNA1mg==
Thread-topic: qa failures on 32-bit debian 7.4

----- Original Message -----
> [...]
> Usually our int64_t use is a result of some api or archive format
> constraint, so I was just hoping to make this obvious in the code that
> we're not relying on this week's definition of "long long" to make the
> code work.

Ah, fair enough.

> > Not really following the need for those macros there.  (return value
> > can always be down-cast for atomvalue.ul vs atomvalue.ull no?)
> 
> True ... the cast will produce an acceptable value, but maybe the wrong
> one.  Consider if long long was indeed 128 bits, then a very, very large

Heh, yep, I wasn't considering numbers beyond 64 bits :)

> Independent of using strtoint64 or strtoll, I need to audit all the code ...

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>