[Coco] 248 errors in NitrOS-9 repository

[Bob Devries]

Lothan said:

> Unfortunately, I don't have commit access to the Toolshed repository and I 
> don't want to say this is the solution (use gcc 4.7 or else) without 
> discussing it with Boisy first.

I'm using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-6gcc -v
ubuntu1) on Linux with no problems, and 4.7.2 on MinGW, and 4.6.3-14+rpi1 on 
RPi.

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message ----- 
From: "Lothan" <lothan at newsguy.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Monday, July 22, 2013 7:11 AM
Subject: Re: [Coco] 248 errors in NitrOS-9 repository


> From: Robert Gault
>
>> Well here is a clue.
>> test disk kyumgai.dsk
>>
>> after compiling with many 248 errors:
>>
>> os9 free kyumgai.dsk
>>
>> "Kyum-Gai: To Be Ninja" created on 07/20/2013
>> Capacity: 360KB (1440 sectors) 1-sector clusters
>> 1130 Free sectors, largest block 1130 sectors
>> Free space: 282KB (289280 bytes)
>>
>> from NitrOS-9 on kyumgai.dsk in drive0:
>>
>> free /d0
>>
>> "Kyum-Gai: To Be Ninja" created on: 2013/07/20
>> Capacity: 1,440 sectors (1-sector clusters)
>> 1,130 free sectors, largest block 932 sectors
>>
>> Note that while the total number of free sectors is reported the same, 
>> the report for largest block count is different. I've checked the count 
>> myself and 932 is correct. Os9.exe is miscalculating the largest free 
>> block.
>> If os9.exe thinks a sector is free, tries a copy, and finds the sector 
>> full, that might be the cause of the 248 error.
>
> I recompiled os9.exe using  4.7.3 and this is what I'm getting now:
>
> "Kyum-Gai: To Be Ninja" created on 07/21/2013
> Capacity: 360KB (1440 sectors) 1-sector clusters
> 694 Free sectors, largest block 694 sectors
> Free space: 173KB (177664 bytes)
>
> I checked the make log after doing a full rebuild and the only 248 errors 
> I am getting are in the Dragon disks. I haven't checked, but I suspect 
> those Dragon disks are probably full.
>
> Now to the real meat of the problem. When I tried to rebuild toolshed with 
> gcc 4.7.3, it consistently failed on all references to _finddata_t and the 
> Windows findfirst*/findnext* API. Apparently these Windows API functions 
> have been replaced with POSIX versions of dirent and appropriate calls to 
> opendir, readdir, etc.
>
> To make a long story short, I went through the Toolshed code and 
> effectively removed the WIN32 conditionals until Toolshed built without 
> any errors. I also had to add appropriate casts on all the malloc, 
> realloc, and calloc calls because the newer GCC is stricter regarding 
> automatic type conversions. This means there is a lot less conditional 
> code, which I think is a good thing.
>
> Unfortunately, I don't have commit access to the Toolshed repository and I 
> don't want to say this is the solution (use gcc 4.7 or else) without 
> discussing it with Boisy first.
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco