gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Corrupted heap


From: Vincent Richomme
Subject: Re: Corrupted heap
Date: Fri, 19 Mar 2010 13:55:16 +0100
User-agent: RoundCube Webmail/0.2

On Fri, 19 Mar 2010 11:50:41 +0000, Richard Frith-Macdonald
<address@hidden> wrote:
> On 19 Mar 2010, at 11:26, Vincent Richomme wrote:
> 
>> On Fri, 19 Mar 2010 09:31:10 +0000, Richard Frith-Macdonald
>> <address@hidden> wrote:
>>> On 18 Mar 2010, at 13:27, Vincent Richomme wrote:
>>> 
>>> 
>>>> And apply the patch I have provided a few days ago to fix some cast
>>>> issues
>>>> and wrong data type(unsigned replaced by socklen_t) on
>> msys/mingw{-w64}?
>>> 
>>> Unless I've missed a patch, I think this was already applied, but then
>> you
>>> supplied a new version of the patch (which won't apply because the
first
>>> one has already been applied).
>>> 
>>> Looking at the actual content of the second version of the patch, I
>> think
>>> this version shouldn't be applied anyway:
>>> 
>>> It casts the buffer arguments of send() and recv() to be const char*
and
>>> char* instead of the const void* and void* that they are now.
>>> 
>> 
>>> The current types are correct (for unix and linux and mingw32 and
posix
>>> and xopen). 
>>> It looks like microsoft chose to use incorrect types when they copied
>> the
>>> unix apis for winsock, and I guess mingw32 chose to use the
>>> original/correct types, but presumably mingw64 uses the microsoft
>> specific
>>> version (was this an accident/mistake or an intentional decision?
>> 
>> Hum are you sure because when I look at original mingw includes I can
>> see
> 
> I am sure that void* is what the posix standard says (and what unix and
> gnu/linux systems use).
> I assumed that's what mingw32 does ... simply because I haven't noticed
> warnings on windows ... but possibly we already have casts there.
> 
>> So it means this is not mingw-w64 specific but is shared by both
project.
> 
> In that case, making the cast mingw specific rather than mingw64
specific
> would do.


It's what I did, actually I don't make any differences between both
project
so a #ifdef __MINGW32__ will work for mingw{64}.
I know that Microsoft doesn't respect the standards but when compiling on
this
platform I suppose it's better to use their conventions.
But actually people using GNustep on windows are not very common so I
won't 
fight for this patch and it's only warnings, it doesn't prevent you from 
building.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]