[Libbt-devel] Re: Need some "other than Mac" checking done

[Alien <ali...@us...>]

hey,

good job, except that i don't work the with 1.03 codebase, you'll have to g=
et=20
this to Kevin, I don't use the 1.03 codebase in CVS HEAD, and frankly, the=
=20
util.c and util.h isn't really used much anymore, I do intend to keep most=
=20
stuff independant of platform...

I'm almost done reworking the CVS HEAD, until it is a little functional, no=
t=20
optimized in the least...

when it's more or less working, i'll send you a mail asking you to compile =
it=20
on mac...

about your patch:

well, I cannot compile it, for the simple reason that I only have linux, an=
d i=20
only have 64bit system, branch 1.03 has never worked for me before...

so, i could not even test your files if i wanted to...

i'll forward this mail to the mailing list, and we'll see if anything=20
happens...

good job, though...

AL13N

Op donderdag 5 mei 2005 23:38, schreef Dakidd:
> Hey guy...
> I think I've managed to knock the kinks out of util.c/util.h for use on
> Macs. I need somebody who can compile for Windows/Unix to check it out and
> see if I screwed up and trashed things for those platforms, or if my
> surgery managed to fix the Mac troubles, yet still leave the "other
> platforms" functional.
>
> The most obvious change (aside from "prettifying" the code - No offense
> intended against Kevin, but he writes code that, in my opinion, is all but
> completely unreadable) is that cacheopen() now takes a void * rather than=
 a
> char * as its first parameter - I *THINK* I've included the right "magic"
> to make this transparent, but I haven't got a way to test that theory. If
> you're wondering about the reason for this, it's kinda in-depth and a pain
> to explain, but I can give you the 411 if you really think it's needed. T=
he
> short version: Macs are *MUCH* happier dealing with files when they're
> passed around as an FSSpec rather than pathnames. There's a lot of voodoo
> involved, but it boils down to "if you want it to work properly in all
> situations on a Mac, do it with FSSPec structs instead of pathnames,
> otherwise, expect to hear your users screaming at you about meltdowns that
> happen for no apparent reason."
>
> I've done my best to conditionalize my changes (on the "TARGET_MACOS"
> value, set up in config.h) so that Unix/Windows can continue passing in a
> char * with a fully-qualified pathname and never notice a difference, whi=
le
> Macs will pass in an FSSpec, but have no way to test the Unix/Windows
> functionality.
>
> I've also done some cleanup and rewiring in the cacheopen() routine -
> You'll notice that the "mode" and "options" parameters have been renamed -
> Those two drove me absolutely *NUTS* until I finally broke down and
> "hand-executed" the code. The names were hideously confusing, and once I
> got through things, it became clear that Kevin had screwed the pooch
> bigtime - "options" gets passed in only when setting up a "writeable" fil=
e,
> and is the Unix file-access permission setting that should be used when t=
he
> file is created. As it was coded, it was being stored as one of the things
> to look at for deciding whether the file was open and cached or not. *BIG*
> screwup! It's obvious (now that I've "hand-executed" it) from looking at
> the rest of the routine that the intention was to open/cache a file based
> on its name and whether it was opened for read or write mode. Checking
> against the file permissions is pointless, and was the source of some maj=
or
> hair-pulling as I tried to figure out why nothing I did would make the
> routine work as expected on a Mac. This forced changes to the cache
> struct/array (c_fileset), and some rewriting of the code that worked with
> it.
>
> openPath() has also been reworked, again mainly to deal with the "Macs li=
ke
> FSSpecs better than pathnames" concept, and again, I believe I've managed
> to make the alterations transparent to Unix/Windows systems through
> conditionals.
>
> If you look through util.c, you'll also notice some "brain surgery" on the
> btAlloc/btMalloc/etc routines - This was done in the interest of
> speed/efficiency - I have yet to meet a library on the Mac that doesn't e=
nd
> up calling directly into the OS for malloc/calloc/realloc/etc calls exact=
ly
> as I do in the revised routines, but with idiotic amounts of useless
> overhead before doing so. So I've basically "chopped out the middleman" a=
nd
> gone straight to the MacOS toolbox routines - which are as old as the Mac
> itself, stable as a rock, and quite well documented - where the
> Windows/Unix versions got things done by way of the standard library
> routines. Operation for them shouldn't be affected, due to conditional
> compilation on the "TARGET_MACOS" value, but on the Mac, it's a good bit
> quicker.
>
> Overall, I've done some pretty major surgery throughout util.c, but I'm
> pretty sure that I've either made the needed changes compatible with, or
> transparent to, Unix and Windows systems by use of conditional compilation
> keyed on the "TARGET_MACOS" value.
>
> Now I need you (or someone else capable of compiling on Windows and/or
> Unix) to check and see if my changes are as compatible/transparent as I
> hope they are...
>
> Basically, "They work on my Mac. Do they still work on other platforms?"
>
> My altered versions (starting from the 1.03 version of the codebase) are
> attached. They might need line-end tweaking to be readable (Macs use '\r',
> windows '\n\r', and unix '\n') Let me know what you come up with, eh?
>
> (Oh - If you reply from somewhere other than your sourceforge.net address,
> make sure to put the string "PopperAndShadow" somewhere in the subject li=
ne
> - I've had to go to full-out email lockdown due to getting hit with more
> than 150 spams a day. I've got your sourceforge address whitelisted, but =
if
> you reply from somewhere else, I've got my procmailrc file set up to send
> *EVERYTHING* that isn't whitelisted straight to dev/null unless the subje=
ct
> line has the "PopperAndShadow" password in it somewhere - I might find out
> (far too late for it to make a difference) that you sent something if I
> notice in my procmail log, but otherwise, I'll never even know it existed)