On 09/10/15 15:41, Nathan Scott wrote:
----- Original Message -----
I'm back in the QA mole smacking business ... these look like wrong size
for metrics in a pmda to me ...
[82%] 872 - output mismatch (see 872.out.bad)
876c876
< value 102044242908
---
> value 4294967295
909c909
< value 102055075867
---
> value 4294967295
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.
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.
But this requires an audit of all strto[u]l[l] uses in the code base
(most of which are OK because they are extracting a value into an
(unsigned) int, or an (unsigned) long or an (unsigned) long long, but
there are a _lot_ of cases, so I'll be a bit longer on this one).
[79%] 845 18s ... - output mismatch (see 845.out.bad)
20,21c20,23
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 ...
|