Thanks for the feedback.
2010/6/16 Bakul Shah bakul+pl...@bitblocks.com:
On Wed, 16 Jun 2010 11:11:09 +0200 hugo rivera uai...@gmail.com wrote:
Can someone clarify why the program included outputs 'AB00' (as I
expect) on 32 bit systems and 'AB00' on 64 bit systems?
where all
Can someone clarify why the program included outputs 'AB00' (as I
expect) on 32 bit systems and 'AB00' on 64 bit systems?
where all those 1's came from? what's the portable way of doing this?
sorry for newbie questions like this.
unsigned long l;
unsigned char c;
On Wed, Jun 16, 2010 at 11:11:09AM +0200, hugo rivera wrote:
printf(%lX\n, l);
Would you try %luX? It may work better?
++L
2010/6/16 Lucio De Re lu...@proxima.alt.za:
On Wed, Jun 16, 2010 at 11:11:09AM +0200, hugo rivera wrote:
printf(%lX\n, l);
Would you try %luX? It may work better?
no, or at least not as I intend. It produces '2868903936X' on 32 bit
linux and '18446744072283488256X' on 64 bit.
On 06/16/10 10:11, hugo rivera wrote:
Can someone clarify why the program included outputs 'AB00' (as I
expect) on 32 bit systems and 'AB00' on 64 bit systems?
where all those 1's came from? what's the portable way of doing this?
sorry for newbie questions like this.
check the ASM, looks like c is being cast as signed and then sign
extended into a long and then ORed with l.
perhaps this would solve it :
l |= ((unsigned long) c) 24
that works. the extra () are unnecessary.
i think that gcc is using 6.3.1.1 and converting
c to an int (since it fits)
On Wed, 16 Jun 2010 11:11:09 +0200 hugo rivera uai...@gmail.com wrote:
Can someone clarify why the program included outputs 'AB00' (as I
expect) on 32 bit systems and 'AB00' on 64 bit systems?
where all those 1's came from? what's the portable way of doing this?
sorry for
