Hi Charlie, On Fri, 18 Dec 2020, Karoly Balogh (Charlie/SGR) via fpc-pascal wrote:
> > I also see that the pre-installed version was installed with the clock > > in the system was set to the start of the Amiga Time (1.1.1978). Might > > that create a problem? > > Actually, yes. If I reset the timestamp of the system unit to 1978-1-1, > 00:00:00 (the start of the Amiga Epoch), I can reproduce the issue on my > system and installation (which is a real '060 + AmigaOS 3.1). So the root cause is, Amiga follows the non-Unix codepath for DateTimeToFileDate inside the sysutils unit, which is artificially limited to dates between 1980 and 2099: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/sysutils/dati.inc?annotate=47808#l1260 This is super old code, it was already there 15 years ago, at the time of the SVN import... I guess the original intention was to keep us compatibile with MSDOS/old FAT file timestamps, which can actually represent dates between 1980 and 2107. (So no idea where 2099 comes from... Because Windows actually counts file dates from 1601 (fix me?), and more modern FSes no longer have the limitation mentioned above anyway.) Anyway, this means FileAge function for Amiga will return zero for dates before 1980, which then causes various havoc down the line. More specifically, later the compiler calls FileDateToDateTime from (see globals.pas filetimestring()) to print a debug message into the verbose log (normally thrown away, actually, but available as fpcdebug.txt with the -vv parameter), which then blows up in sysutils/EncodeTime, because zero is an invalid file timestamp actually as far s the MSDOS timestamp format is concerned, because you get zero as day and month (and year too, just the code adds 1980 anyway... :) ) Yuck. :P What a nice juicy can of worms... Found just because someone used a buggy LhA to decompress Free Pascal on Amiga... :D I'm not touching this for any other platform, because ... Just no. :D But as the FileAge return value and the FileDate format should be OS specific, on the mid-run I'll migrate the Amiga code away from the non-Unix codepath, to something custom. Probably to something very similar to the Unix codepath, but counting the Epoch from 1978-01-01 instead of 1970-01-01... Or a packed/smaller version of the AmigaOS DateStamp structure. This has other advantages, for example the Amiga RTL will no longer be limited to 2 seconds resolution when working with file timestamps, another MS-DOS/FAT legacy coming from the generic code paths. Thanks Carsten, for this report. As much as we usually get invalid reports regarding the Vampire, this was genuinely useful. For now, please use the workaround I mentioned in my previous e-mail, because this will take a while to fix. I'll also try to get a quick fix into the compiler, to make it not blow up with an exception at least, because the compiler code seems to be prepared to work with invalid timestamps otherwise. Cheers, -- Charlie _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
