Re: Base status

[Richard Frith-Macdonald]

On 17 Aug 2011, at 10:45, Fred Kiefer wrote:

> I really would like to see the 1400 test errors we get on MinGW reduced 
> before the next release.

I agree ... mingw is probably our second highest priority platform after 
gnu/linux, so major problems there 
How are you building it?  Recent (not necessarily very recent ... I haven't 
tried for weeks) changes seem to have completely broken the build of base on 
mingw for me.

buildfail.log
Description: application/applefile

> As far as I can tell most of this boil down to GSMime issues (The NSURL test 
> seems to be a result of that as well). Even the most simple test in GSMime 
> build.m produces the wrong result. Only the last header and the content get 
> reported as the rawMimeData.
> As debuggin on MinGW is a rather annoying task, especially when done in a 
> virtual machine, I looked through the code at GSMime to find any MinGW 
> specific issue and there aren't any. So I furteher tracked this down until I 
> got to the method -headerNamed: which always returned the first element what 
> ever the given name was. There we use this horrible optimisation of 
> implementation caching. Fine if done correctly, but here we use the type IMP 
> to cache a method that returns a BOOL not an object. I will fix this later on 
> and give the MinGW testing another try. in GSMime.m I could see about five of 
> this misuses of IMP and we will have to check the rest of base as well.

Traditionally IMP was supposed to be fine for any method returning a scalar 
type ... but I guess that was back in the (NeXTstep) days where all the ABIs 
passed such return values back by setting the value of a register.  Nowadays 
the use of IMP is definitely no longer safe, and we should check all code as 
you say.   In fact we should probably periodically review this kind of thing 
... optimisations which were necessary when the code was originally written may 
no longer be important (or even be counter-productive) with modern CPUs and 
compilers. 

> Still no idea why this breaks on MinGW but seems to work on most other 
> systems.

I thought most tests used to pass on MinGW too.