🚀 go-pugleaf

In article <10102@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes:
>> EA decided in it's infinite wisdom, and to my chargin, to allow
>> chunks of odd sizes. This screwed up my primitive IFF parsing so that
>> iff2sun would probably only work half of the time (yech).

>No!  Someone tell me this isn't true.  First, someone verify that
>Dpaint III does generate BROKEN IFF files in this manner.  Second,
>where and when was the standard `revised'?  I think this is a bug in
>Dpaint III if they are really doing this, and I will be seriously
>pissed if they've made this change . . .

 But does this mean that the IFF format is broken? I didn't think so.
I though that IFF chunks were allowed to be of any length, it just so
happened that everybody wrote ILBMs with chunks of an even size, so I
didn't notice the problem until I got a bug report (and code fix).

 I mean, I *knew* that the way I do IFF parsing in iff2sun is not the
_correct_ way. I don't read the length attribute and skip to the next
chunk based on this value, I just skip along the file until I find the
ascii string "BODY" (for example). In order for this hack to work, I
needed to have all of the chunks aligned on an even boundary. This was
true of all the IFF ILBMs I've tried until now. I don't have any
DPaintIII files handy so I can't verify the change, but more than one
person has complained of the problem to me, and my new and improved
(although not really fixed) parsing scheme *works*. All I did was to
do my checking on a byte basis rather than on a word.

 Before all you software types jump all over my case, try to keep in
mind that I'm a hardware jock mostly. Software is something I do for 
fun. If you can do it better, please do and send the code to me. I'll
thank you for it. :-)



Steve -Raz- Berry      Disclaimer: I didn't do nutin!
UUCP: sun!kilowatt!raz                    ARPA: raz%kilowatt.EBay@sun.com
KILOWATT: sun!kilowatt!archive-server     archive-server%kilowatt.EBay@sun.com