[Coco] 248 errors in NitrOS-9 repository

[Tormod Volden]

On Sun, Jul 21, 2013 at 11:11 PM, Lothan wrote:
>
> 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)

Interesting that it changed with 4.7.3 but it could be a coincidence also.

>
> 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.

Yes, I think they are really full, from summing up the file sizes on the image.

>
> 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

Why would this change from gcc 3 to gcc 4? Are other libraries linked
in by default?

And if removing WIN32 conditionals worked, would simply removing
-DWIN32 from the makefile work? Or were there some conditionals left
that were needed?

> 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.

Please attach your patch to the bug tracker
https://sourceforge.net/p/toolshed/bugs/ and it would be especially
good if you keep the malloc/etc cleanup separate from the WIN32
changes.

Tormod