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