| 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> |
|---|---|---|
| ||
| Previous by Date: | [Bug 1268322] vector bundling broken in scripts/spin-rawhide, bugzilla |
|---|---|
| Next by Date: | ÐÑÐÐÐÑ: ÐÑÐÐÑ ÐÐÑ ÐÐÐÑÑÐÐÐÑ ÑÑÑÐÐÑÐÐÐÐÑÑÐ ÐÐÐÐÐÐÐÐ..., ÐÐÐÐÐÑÐÑÐ ÑÐÑÐÐÐÐÐÐÑ |
| Previous by Thread: | Re: [pcp] qa failures on 32-bit debian 7.4, Ken McDonell |
| Next by Thread: | RE: [pcp] qa failures on 32-bit debian 7.4, Ken McDonell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |