Oh, I tried with VC6 btw (which is below the version check in wdm.h),
and it seemed to generate both function and call correctly the way
modern compilers do.
This type of problem isn't super easy to notice though, since most
functions will just "mov esp, ebp" or "leave" and thus restore the
correct stack pointer again. So maybe it was simply a bug in the
function, and it was only noticed after everything was already switched
to the macro anyway.


On 2014-10-16 20:28, Timo Kreuzer wrote:
> 
> - The internal symbol (according to public symbols) has fastcall decoration
> - The function is exported without decoration
> - The wdm.h header for example uses the fastcall declaration, but only 
> for very old compilers, otherwise an intrinsic
> The reason might have been a compiler bug in earlier versions of VC, 
> like this one from Borland: http://qc.embarcadero.com/wc/qcmain.aspx?d=5040
> 
> Am 16.10.2014 12:19, schrieb Hermès BÉLUSCA - MAÏTO:
>> How is this function really exported *and* used through windows?
>>
>> -----Message d'origine-----
>> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Timo Kreuzer
>> Envoyé : mercredi 15 octobre 2014 21:45
>> À : ReactOS Development List
>> Objet : Re: [ros-dev] [ros-diffs] [tfaber] 64749: [PSDK] - Use macro version
>> of RtlUlonglongByteSwap in winternl.h because using the fastcall version
>> causes stack corruption CORE-8632 #resolve
>>
>>
>> What I really wonder: since the function behaves like cdecl, why does wine
>> declare it as fastcall? Or is this also our own hack, because the function
>> has fastcall symbols and it's declared as fastcall in wdm.h for compilers
>> with _MSC_FULL_VER <= 13009037?
>> IMO we should remove all traces of it being fastcall and simply declare it
>> as cdecl. There is no reason to reproduce MS header bugs.
>> And we should probably also kill the asm file for it. There is no need for
>> it.
>>
>> Am 15.10.2014 19:11, schrieb Thomas Faber:
>>> It's there for Wine compatibility. Things we would put in NDK, they
>>> put in winternl.h.
>>>
>>>
>>> On 2014-10-15 19:08, Ged Murphy wrote:
>>>> There shouldn't really be anything using this header
>>>>
>>>> -----Original Message-----
>>>> From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of
>>>> tfa...@svn.reactos.org
>>>> Sent: 15 October 2014 17:38
>>>> To: ros-di...@reactos.org
>>>> Subject: [ros-diffs] [tfaber] 64749: [PSDK] - Use macro version of
>>>> RtlUlonglongByteSwap in winternl.h because using the fastcall version
>>>> causes stack corruption CORE-8632 #resolve
>>>>
>>>> Author: tfaber
>>>> Date: Wed Oct 15 16:38:13 2014
>>>> New Revision: 64749
>>>>
>>>> URL: http://svn.reactos.org/svn/reactos?rev=64749&view=rev
>>>> Log:
>>>> [PSDK]
>>>> - Use macro version of RtlUlonglongByteSwap in winternl.h because
>>>> using the fastcall version causes stack corruption
>>>> CORE-8632 #resolve
>>>>
>>>> Modified:
>>>>       trunk/reactos/include/psdk/winternl.h
>>>>
>>>> Modified: trunk/reactos/include/psdk/winternl.h
>>>> URL:
>>>> http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/wintern
>>>> l.h?rev=64749&r1=64748&r2=64749&view=diff
>>>>
>> ============================================================================
>> ==
>>>> --- trunk/reactos/include/psdk/winternl.h  [iso-8859-1] (original)
>>>> +++ trunk/reactos/include/psdk/winternl.h  [iso-8859-1] Wed Oct 15
>> 16:38:13 2014
>>>> @@ -2310,7 +2310,12 @@
>>>>    BOOLEAN   WINAPI RtlTimeToSecondsSince1980(const LARGE_INTEGER
>> *,LPDWORD);
>>>>    BOOL      WINAPI RtlTryEnterCriticalSection(RTL_CRITICAL_SECTION *);
>>>>    
>>>> +#ifdef __REACTOS__
>>>>    ULONGLONG __fastcall RtlUlonglongByteSwap(ULONGLONG);
>>>> +#define RtlUlonglongByteSwap(_x) _byteswap_uint64((_x)) #else
>>>> +ULONGLONG __cdecl RtlUlonglongByteSwap(ULONGLONG); #endif
>>>>    DWORD     WINAPI RtlUnicodeStringToAnsiSize(const UNICODE_STRING*);
>>>>    NTSTATUS  WINAPI
>> RtlUnicodeStringToAnsiString(PANSI_STRING,PCUNICODE_STRING,BOOLEAN);
>>>>    NTSTATUS  WINAPI RtlUnicodeStringToInteger(const UNICODE_STRING
>>>> *,ULONG,ULONG *);
>>>>
>>> _______________________________________________
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
> 
> 
> _______________________________________________
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
> 


_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Reply via email to