1.34 boost::filesystem::size() issues on OSX PPC (works on OSX Intel though)
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? Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com
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? Does this happen on all files, or only on certain files? Is there any chance this is Mac OSX issue rather than a Boost.Filesystem issue? Thanks, --Beman PS: I'll be away from email all weekend, so won't be able to look into this until next week.
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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
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
In message <87k5s3e6bc.fsf@grogan.peloton>, David Abrahams <dave@boost-consulting.com> writes
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.
But some processors have switchable byte ordering for data access. See the Bi-endian hardware entry in: http://en.wikipedia.org/wiki/Endianness -- Alec Ross
on Fri Aug 10 2007, Alec Ross <alec-AT-arlross.demon.co.uk> wrote:
Note the OP said Intel and PPC. The processor type is the only determinant of byte ordering that I know of.
But some processors have switchable byte ordering for data access. See the Bi-endian hardware entry in:
Yow, PPC is one of those. Sorry! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Dave et al, I found the issue I was seeing with boost::filesystem::file_size() a few weeks ago, but figured I should post it here (now that i'm back from Burning Man and all that) in case anyone else is interested. It's not the fault of Boost -- it's gcc. On PPC Macs, compiling using --fast makes boost::filesystem::file_size() return a bad value, though on Intel Macs, --fast is fine. It might be a gcc (or maybe Apple's specific version of gcc) bug, or maybe --fast indeed works differently on PPC and x86. I found it interesting :-)
Note the OP said Intel and PPC. The processor type is the only determinant of byte ordering that I know of.
But some processors have switchable byte ordering for data access. See the Bi-endian hardware entry in:
Yow, PPC is one of those. Sorry!
Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com
participants (5)
-
Alec Ross -
Beman Dawes -
David Abrahams -
John Zorko -
Martin Bonner