Re: [Tinycc-devel] 0.9.26 regression on WIN32 - utime() links to _utime32 instead of _utime in msvcrt.dll

[Peter]

>----------------------------------------
>From: address@hidden
>Date: Wed, 26 Mar 2014 08:04:54 +0800
>To: address@hidden
>Subject: Re: [Tinycc-devel] 0.9.26 regression on WIN32 - utime() links to 
>_utime32 instead of _utime in msvcrt.dll
>2014-03-26 0:10 GMT+08:00 Peter <address@hidden>:
>> ----------------------------------------
>>> From: address@hidden
>>> Date: Tue, 25 Mar 2014 21:19:33 +0800
>>> To: address@hidden
>>> Subject: Re: [Tinycc-devel] 0.9.26 regression on WIN32 - utime() links to 
>>> _utime32 instead of _utime in msvcrt.dll
>>>
>>> 2014-03-25 20:47 GMT+08:00 Peter <address@hidden>:
>> ...
>>>> I have discovered the following problem and submitted a bug 
>>>> http://savannah.nongnu.org/bugs/index.php?41950
>>>>
>>>> The following simple program:
>>>>
>>>> &include <sys/utime.h>
>>>>
>>>> int main(int argc, char **argv)
>>>> {
>>>> utime(argv[1], 0);
>>>> }
>>>>
>>>> compiled win 0.9.26 on WIN32 (Windows XP SP3) links to the - non existing 
>>>> - _utime32 export from msvcrt.dll instead of the correct one (_utime). It 
>>>> compiles correctly with 0.9.25.
>>>>
>>>> There is a ZIP file with all the relevant files attached to the bug report.
>>>>
>>>
>>> Did you try the tip revision in mob branch?
>>> I can't reproduce the bug in mob branch, so it may be fixed in mob branch.
>>
>> Just now I compiled the tcc mob branch. This was the first time ever I used 
>> git so I hope the chekout is correct. I attached the resulting tcc "distro" 
>> in the bug at http://savannah.nongnu.org/bugs/index.php?41950 
>> (20140325_tcc_mob_ruevs.zip). You can see my build process in BuildLog.txt 
>> inside the zip file.
>>
>> The resulting tcc.exe is different from the 0.9.26 release (normal) but 
>> unfortunately the tccutimebug.exe it compiles is identical to the 
>> problematic one compiled by the official release (tccutimebug_0926.exe).
>>
>> Another thing I noticed is that the tcc.exe I built still reports 0.9.26 - 
>> is this normal? Is the version number kept at the last release level during 
>> development in the mob branch?
>
>Oops, I just forget that I have some local patches that haven't pushed
>to mob branch.

Your patches "my-mingw.patch" and "utime_mgw64.patch" do fix the problem.

An even less intrusive patch in utime.h would be:
  +/* FIXME for __MSVCRT_VERSION__>= 0x0800 */
  +#define utime _utime
instead of 
  +/* FIXME for __MSVCRT_VERSION__>= 0x0800 */
  +//_CRTIMP int __cdecl __MINGW_NOTHROW    utime (const char*, struct 
utimbuf*);
and not change _mingw.h at all. It works - I tested it.

I also searched a bit and discovered that that the "utime" problem under WIN32 
is old has been discussed in MinGW at length:
  http://ehc.ac/p/mingw/bugs/1973/?page=4

Your solution maps utime to _utime which is 32 bit and (unlike _utime32) exists 
everywhere.

The ReactOS folks have done the same:
http://code.google.com/p/reactos-mirror/source/browse/trunk/reactos/include/crt/sys/utime.h
http://www.reactos.org/pipermail/ros-diffs/2008-December/027744.html

In MinGW the headers in "include/sys" have gone through many variants of how 
this
 should be done. The current latest thinking in MinGW seems reasonable 
to me:
  
http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/sys/utime.h#l97
It
 makes utime an inline function that calls the 64 bit _utime64 even on 
WIN32. One disadvantage is that it does not exist in very old 
versions of msvcrt.dll (e.g. Windows 95). For TinyCC updating all of the 
headers in include/sys to the current MinGW master branch would require a lot 
of testing though.


________________________
Some further references:

http://sourceforge.net/p/tcl/bugs/5115/

http://msdn.microsoft.com/en-us/library/aa273399%28v=vs.60%29.aspx

"The latest version of the Msvcrt.dll file that is compatible with 
Windows Millennium Edition, with Windows 98, or with Windows 95 is 
version 6.0.9782.0. This version is included with Microsoft Visual 
Studio 6.0 Service Pack 6 (SP6)."
http://support.microsoft.com/kb/895959

http://msdn.microsoft.com/en-us/library/4wacf567%28v=vs.71%29.aspx
http://msdn.microsoft.com/en-us/library/4wacf567.aspx