Posted Nov 17, 2012 22:16 UTC (Sat) by dark (subscriber, #8483)
[Link]
I don't know if it's a good reason, but the C standard doesn't guarantee that an integer zero is represented as all-bits-zero. The loop is in that sense more portable than using memset.
catdoc: denial of service
Posted Nov 18, 2012 7:10 UTC (Sun) by apoelstra (subscriber, #75205)
[Link]
> I don't know if it's a good reason, but the C standard doesn't guarantee that an integer zero is represented as all-bits-zero. The loop is in that sense more portable than using memset.
All-bits-zero is integer zero. It's pointers and floating-point numbers you need to worry about.
catdoc: denial of service
Posted Nov 18, 2012 16:41 UTC (Sun) by dark (subscriber, #8483)
[Link]
Ah ok, thanks. I did some digging and it seems I had this the wrong way around: an integer zero does not have to be all bits zero (because the standard permits padding bits), but C99 explicitly guarantees that all bits zero is interpreted as integer zero. (6.2.6.2/5)
The discussion about this that I remembered was about the language in C89 so I feel old now :) C89 has much less to say about padding bits but doesn't rule them out.
catdoc: denial of service
Posted Nov 18, 2012 20:27 UTC (Sun) by apoelstra (subscriber, #75205)
[Link]
> Ah ok, thanks. I did some digging and it seems I had this the wrong way around: an integer zero does not have to be all bits zero (because the standard permits padding bits), but C99 explicitly guarantees that all bits zero is interpreted as integer zero. (6.2.6.2/5)
Oh! I thought this was true in C89 also.
I wonder, though, when you pass 0 to memset -- are you passing "integer zero" or "all bits zero"? Maybe you are still okay even if nothing is actually all-bits-zero.
catdoc: denial of service
Posted Nov 21, 2012 1:18 UTC (Wed) by gjmarter (subscriber, #5777)
[Link]
Although I wasn't aware of the padding rule before, I think it is a safe bet that memset is doing "all bits zero". It is setting bytes even though you pass it an integer.