sginsberg(a)svn.reactos.org wrote:
> Author: sginsberg
> Date: Sun Jan 18 17:31:26 2009
> New Revision: 38922
>
> URL: http://svn.reactos.org/svn/reactos?rev=38922&view=rev
> Log:
> - Fix more InterlockedCompareExchangePointer warnings in crypt32 -- this to Wine, too
>
> Added:
> trunk/reactos/dll/win32/crypt32/warningfixes.diff
This is a bad idea.
It's painful enough keeping wine libs in sync without adding to the complexity with non-needed warning fixes.
Ged.
hyperion(a)svn.reactos.org schrieb:
> Author: hyperion
> Date: Sun Jan 18 00:25:43 2009
> New Revision: 38872
>
>
...
> Introduce new define __ROS_LONG64__ ("assume 64-bit long"), to use int instead of long in typedefs of 32-bit integers
> __ROS_LONG64__ automatically defined if __WINESRC__ is defined. No, __WINESRC__ alone is not enough
>
If it's defined automatically, why isn't __WINESRC__ alone enough? And
when it's not enough anyway, why define __ROS_LONG64__ automatically at
all?
...
> #else /* !_WIN64 */
> +#if !defined(__ROS_LONG64__)
> typedef int INT_PTR, *PINT_PTR;
> typedef unsigned int UINT_PTR, *PUINT_PTR;
> +#else
> +typedef long INT_PTR, *PINT_PTR;
> +typedef unsigned long UINT_PTR, *PUINT_PTR;
> +#endif
>
If we assume a 64bit long, why define INT_PTR to long on 32 bit target?
> From: Hauke Goos-Habermann <HHabermann(a)pc-kiel.de>
> Date: January 12, 2009 4:53:40 PM GMT+03:00
> To: aleksey(a)reactos.org
> Subject: ReactOS booth/speech at Linux days in Kiel?
>
> Hi Aleksey,
>
> for the Linux days in Kiel in Germany we are searching for
> interesting OSS
> projects. Can you tell me if there are members of ReactOS that may be
> interested in a booth or/and giving a presentation? The "Kieler
> Linux- und
> -OpenSource Tage" will be at 2nd and 3rd of october.
>
> Additional information (in German only) can be found at: www.kieler-
> linuxtage.de
>
> PS. Please forward the mail to interested members.
>
> Cu Hauke
>
> --
>
> Stoppt Softwarepatente, sonst wird Softwareentwicklung in Europa
> für die meisten
> illegal!
> Patentfrei sichert IT-Arbeitsplätze (www.patentfrei.de)
> Sorry I didn't quite get it. ;-) What is ok atm? How are we going to
> handle it?
Extern inline is ok atm. ;-)
I mean that it works well now. And when its behavior will be changed,
gnu_inline attribute can be used to get old (i.e., present) behavior.
> Well that was a workaround, because of "static declaration follows non
> static declaration".
> Then it needs to be done differently. But I don't see any good solution
> that doesn't require lot's of hacks atm, except disabling that warning.
It's ok atm. Attribute gnu_inline can be used to get old inline semantics.