Error during command authentication.
Error - unable to initiate communication with LISTSERV (errno=10061, phase=CONNECT, target=127.0.0.1:2306). The server is probably not started.
Paul Berkowitz wrote on Sun, 25 May 2003 09:17:09 -0700: >On 5/25/03 8:59 AM, "Nigel Garvey" <[log in to unmask]> >wrote: >> It works with every date I've tested so far in the AppleScript date >> range, including those that come before 1904. Because of a Mac OS >> date-subtraction bug, French Vanilla crashes on dates before 1904. (I >> know what you're thinking, but it's a vulnerability nonetheless.) >> >> It turns out that the bug doesn't kick in when a later date is subtracted >> from an earlier one, ... >I came upon a date (and large number) addition-of-a-negative-number bug, >which could put you back a whole Mac epoch (c. 136 years) so you found >yourself in the 1800's instead of 1972. In that case subtraction of positive >numbers was the solution. What's the subtraction bug exactly? Hi, Paul. I think I remember you bringing up the "epoch" problem on one of the lists some time back. I'll have a look through my archives later on. The subtraction bug that affects French Vanilla manifests itself when you have two AppleScript dates, both of which are earlier than 1904, and you try to subtract one from the other. There's an execution error: "The result of a numeric operation was too large." As I discovered the other evening, though, the error doesn't occur if the dates are not equal and the later one is subtracted from the earlier one. Chris Nebel said it was due to a problem with one of the operating system's underlying math routines. Basically, pre-1904 dates are represented by negative numbers (I think). After a subtraction of these that should give a positive number of seconds, the routine responsible misinterprets the combination of processor flags (negative, overflow, and carry) and deduces that the result is a number too large to be represented in the given number of bytes. (I never fully got the hang of this when I dabbled in 68000 assembler a few years ago.) >BTW, do you actually meant the opposite of what you say here: > >> It turns out that the bug doesn't kick in when a later date is subtracted >> from an earlier one, so English Fudge subtracts the January date from the >> original instead of vice versa. > >Won't the January date be _earlier_ than the original one, so don't you want >to subtract the original date from the January one, not vice versa, if you >want a later-from-earlier? You're absolutely right. Thanks for noticing that. And I read it so many times before posting it, too. :-( >And is there really a bug with subtracting a >number from itself - not getting 0 - if the dates are exactly the same in >the case of original dates in January? You still need to subtract 1 to get >an earlier January date? That's the case on my machines. With dates before 1904, only subtracting a later from an earlier will work. The actual amount knocked off the January date can be anything be within a certain range - which I haven't bothered to determine. I used 1 as a cautious bare minimum. NG