Hi Ken,
----- Original Message -----
> On 09/10/15 15:41, Nathan Scott wrote:
> >
> > Hmm, not seeing the cause there - everything on this path looks to
> > be 64 bit, correctly AFAICT.
>
> Yes there is ... linux_table.c uses strtol and should be using strtoll
> on 32-bit platforms.
Good catch!
> This is all a bit messy and inconsistent in the code ... I'm proposing
> introducing strtoint64() and strtouint64() for use where we want to get
> a [u]int64_t from an ascii string ... and then using configure magic to
> #define strtoint64 and strtouint64 to the correct strto[u]l[l] name.
Isn't strtoull always the right thing to use to end up with 64-bit?
Not really following the need for those macros there. (return value
can always be down-cast for atomvalue.ul vs atomvalue.ull no?)
> > This one might be test related (I think we're implicitly converting
> > to int from a ctypes double there, perhaps thats root cause) - does
> > the attached patch help this one?
>
> Haven't had a chance to look at this one yet ...
>
BTW, I pushed that through cos its definitely more correct, even if it
doesn't fix this specific issue & QA passes on x86_64 either way.
cheers.
--
Nathan
|