On 09/26/2012 11:17 PM, Ian Lance Taylor wrote:
On Wed, Sep 26, 2012 at 10:07 PM, JD <jd1008@xxxxxxxxx> wrote:
On 09/26/2012 10:46 PM, Ian Lance Taylor wrote:
On Wed, Sep 26, 2012 at 6:18 PM, JD <jd1008@xxxxxxxxx> wrote:
I came across this patch which could be cause of a bug.
What are possible side effects of this
code segment if compiled under various
non-gnu C compilers, and GCC compilers?
+inline uint32_t NS_MIN(uint32_t a, uint64_t b)
+{
+ return b < a ? b : a;
+}
Nit: Please cast the 64-bit variable to 32-bit in case compilers start
warning about it.
+ *pProgress = NS_MIN<PRUint64>(totalBytes - bytesLeft,
PR_UINT32_MAX);
It's very hard to determine the behaviour of an incomplete program.
It's even harder when you show us two incompatible code fragments.
You are defining a non-template function NS_MIN and calling a template
function NS_MIN. I would expect a compiler error. I don't know what
you are seeing.
The basic groundrules for this kind of question are: tell us precisely
what you did, tell us precisely what happened, and tell us what you
expected to happen instead.
Ian
I was hoping to see what programmers would have to
say about comparing unsigned 32 bit with unsigned 64 bit
in the line
return b < a ? b : a;
does the C compiler first promote the 32 bit to 64 bit before the
comparison
or vice versa - the 64 bit demoted to 32 bit before comparison.
Please reply to the mailing list, not just to me. Thanks.
if you compare an unsigned 32-bit value to an unsigned 64-bit value,
the unsigned 32-bit value will be zero-extended to 64-bits, and the
values will be compared as unsigned 64-bit values.
Ian
Thanx - but,re responding - Thunderbird did that when I clicked on Reply.
It replied to you instead of mailing list. Sorry about that. Will watch
for it
next time.
Re: zero extending the 32 bit value by the compiler before comparison.
Is it zero extended on left or on right?
Thanx,
JD