Bug #19387 for Mac-Carbon: Mac::Resources has endian problems on intel systems

Sun May 21 10:39:25 2006 Guest - Ticket created

Subject:

Mac::Resources has endian problems on intel systems

$ perl -v This is perl, v5.8.8 built for darwin-2level Mac::Resources, from Mac::Carbon 0.74, builds ok on intel (10.4.6), and 'make test' says ok, but attempting to read any resource fork produces garbage. I'm guessing that this is because the byte-order of the resource fork is swapped with respect to the intel CPU's natural byte- order. Simple test case: $ perl -Mstrict -we ' use Mac::Resources; my $r = FSOpenResourceFile("encore.sd2", "rsrc", 0) or die $!; my $c = CountTypes(); my $t; for (1 .. $c) { $t = GetIndType($_); print "$_ : $t\n"; }' 1: RTS 2: LMds 3: LLds 4: LRdd 5: WEVo 6: LTNC 7: TRLA 8: xrla 9: LTID ...etc This file actually has only four resource types. One is 'STR ', which we can see in byte- swapped form on line 1 of the output.

Sun May 21 20:37:26 2006 Guest - Correspondence added

Here's a workaround for the byte-order. Note that I was using CountTypes(), above: I meant to use Count1Types(). That explains the more-types-than-expected issue. $ perl -Mstrict -we ' use Mac::Resources; my $r = FSOpenResourceFile("encore.sd2", "rsrc", 0) or die $!; my $c = Count1Types(); my $t; for (1 .. $c) { print "$_: \"" . join("", pack("(L)*", unpack("(N)*", GetIndType($_) ))) . "\"\n"; }' 1: "STR " 2: "sdML" 3: "sdLL" 4: "ddRL" 5: "oVEW" I'm not very handy with pack and unpack, but I believe this will read the type (an OSType, which is a C4 in big-endian) in big-endian, but pack it into the local machine's native format. Similar workarounds could handle the other functions in Mac::Resources. In the long run it'd be nice if Mac::Resources were smart enough to do this for us. Apple has released a fair amount of docs on the whole PPC-Intel endian issue, but I'm not quite savvy enough to try a patch.

Sun May 21 20:37:27 2006 The RT System itself - Status changed from 'new' to 'open'

Wed May 24 01:39:04 2006 cnandor [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #19387] Mac::Resources has endian problems on intel systems
Date:	Tue, 23 May 2006 22:28:06 -0700
To:	bug-Mac-Carbon [...] rt.cpan.org
From:	Chris Nandor <cnandor [...] cpan.org>

I've got a patch which should automagically fix this. You can try it if you want, it's attached below (if you do try it out, please let me know if it works). There are other potential problems out there, and this patch should fix most of them: any that return or accept an OSTYPE. I am hoping to get access to an Intel Mac soon so I can actually do more testing etc. =================================================================== RCS file: /cvsroot/macperl/perl/macos/ext/Mac/Carbon/typemap,v retrieving revision 1.4 diff -u -r1.4 typemap --- typemap 20 Feb 2005 05:57:13 -0000 1.4 +++ typemap 24 May 2006 04:38:44 -0000 @@ -32,7 +32,8 @@ T_STR255 MacPerl_CopyC2P(SvPV_nolen($arg), $var) T_OSTYPE - memcpy(&$var, SvPV_nolen($arg), sizeof($ntype)) + memcpy(&$var, SvPV_nolen($arg), sizeof($ntype)); + $var = htonl($var); T_RECORDREF if (SvROK($arg)) memcpy(&$var, SvPV_nolen((SV*)SvRV($arg)), sizeof($ntype)); @@ -73,7 +74,9 @@ T_STR255 sv_setpvn($arg, ((char *) $var) + 1, $var\[0\]); T_OSTYPE - sv_setpvn($arg, (char *) &$var, 4); + { OSType hos = ntohl($var); + sv_setpvn($arg, (char *) &hos, 4); + } T_RECORDREF sv_setref_pvn($arg, \"${ntype}\", (void*)&$var, sizeof($ntype)); T_RECORDOBJ -- Chris Nandor pudge@pobox.com http://pudge.net/ Open Source Technology Group pudge@ostg.com http://ostg.com/

Mon Jun 19 22:20:02 2006 cnandor [...] cpan.org - Status changed from 'open' to 'resolved'