Hi, Goswin. First of all, thank you very much for the help. And sorry for the abrupt lack of responses there after some point in our discussion. I had a power outage here lasted for longer than 5 hours (!).
On May 24 2008, Goswin Brederlow wrote: > after you mentioned your difficulties with 64bit on irc I looked at it > and it was quite simple to fix. I guess that a lint-like thing (like gcc is) is a good thing for the source. :-) > There are 2 things they did wrong (in regards to 64bit, lots of other > stuff wrong there too :). Thanks for spotting the problems. > First BTPrivate.h: > > - UInt32 refCon; > // Used by DFA to point to private data. > + struct BTreeExtensionsRec *refCon; > // Used by DFA to point to private data. Ugh! The assumption that sizeof(unsigned) is the same of that of a pointer is indeed a bad assumption. > The refCon is always used as pointer to a struct BTreeExtensionsRec so > I added a forward declaration of the struct and made it a pointer to > one. I have no problems with that and it would be actually the way I would code it. > The code works fine with "void *refCon" though as it is cast correctly > when used. Use that if you don't like the forward declaration. Typecasts are evil, unless you really know what you're doing (I use it on my code, but I am supposed to know what I do with my own code). :-) > All that remained then was to remove the (UInt32) casts for all refCon usage. Yes, I saw that. > Secondly: > nextRecord = (char *)src->buffer + srcOffs[i-1]; > > A construct like that is used several times with i=0 to get > srcOffs[-1]. The problem here is "UInt32 i". When i=0 the i-1 gives > 4294967295 and not -1. Agreed here, since we are using two's complement (the most common way of storing integers on modern machines). > In 32bit that results in the same because the array pointer overflows. Do you mean that using 0xffffffff as an index in an array (on 32 bit arches) does the same thing as using -1? Never heard of that before, but nice to know (and to test here after writing this e-mail). > But in 64bit it happily accesses element 4294967295 and segfaults. By > changing i to int the desired [-1] is used. Agreed again. We do need i to be signed if -1 is to be used (which I'm not exactly sure that is a proper thing to do). > With these two changes both mkfs and fsck run on /dev/ram0. Thank you so much. BTW, I use a loop filesystem to do that (avoiding the need of a ramdisk). Just a comment for you, since, then, we can have arbitrarily sized filesystems. :-) > The patch removes the -m32 from rules and adds -W to CFLAGS. Thanks. It was a kludge anyway. > There are a lot of warnings there that warant cleanup but nothing > obviously wrong. Now someone has to do some real life testing to see > if any other 64bit problems remain. That was nasty. I think that now a proper upload to unstable is asked for. Thanks again, Rogério. P.S.: Are you willing to help package this cleaning up the code and possibly feeding the patches upstream? P.P.S.: I saw that you are a co-maintainer of ia32-libs together with Bdale Garbee. What a small world! :-) -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
