David Abrahams wrote:
on Fri Aug 10 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
John Zorko wrote:
Hello, all ...
When I use v1.34s boost::filesystem::size() implementation on Mac OSX (10.4.10, Intel and PPC), I get different results. It appears to be a byte-ordering issue (since on little-endian machines (I tested on Windows and OSX Intel) it returns the correct result, while on big- endian machines (I tested on OSX PPC) it does not). While this is easy enough to code around, I don't recall reading anything about byte-ordering issues in the boost::filesystem portability guide, so i'm wondering if this is intentional?
No, certainly not!
By different results, do you mean the size that is returned is wrong? Is the size correct if the byte-order is swapped?
Note the OP said Intel and PPC. The processor type is the only determinant of byte ordering that I know of.
Yes, but I understood Eric to be asking something like: If the actual size is 42 bytes, does the answer on OSX PPC look like 0x2A000000, or does it look like 0xDEADBEEF? -- Martin Bonner Project Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com disclaimer