Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

[Steven Edwards]

On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget  wrote:
> I moved them after the windows.h include though in practice the needed
> winnt.h has already been included by the time we include winetest.h. So
> maybe windows.h should be nuked altogether...

Conversely maybe using windows.h usage should be fixed and used more
often. Wine is an oddball when it comes to win32 program with the
excessive lengths it goes to, to avoid using windows.h. I am starting
to think even avoiding it internally like we do causes more harm than
good as far as being source compatible with MSVC.

winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

[Dmitry Timoshkov]

"Steven Edwards"  wrote:
> Conversely maybe using windows.h usage should be fixed and used more
> often. Wine is an oddball when it comes to win32 program with the
> excessive lengths it goes to, to avoid using windows.h. I am starting
> to think even avoiding it internally like we do causes more harm than
> good as far as being source compatible with MSVC.

The reason why we avoid windows.h inclusion in Wine is compilation
time by avoiding inclusion of all-in-one headers windows.h does. It's
always a good programming practice to include only those .h files that
are really needed, inclusion of windows.h usually shows the ignorance
and lack of knowledge of a programmer.

winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

[Steven Edwards]

On Tue, Feb 17, 2009 at 10:40 PM, Dmitry Timoshkov
 wrote:
> The reason why we avoid windows.h inclusion in Wine is compilation
> time by avoiding inclusion of all-in-one headers windows.h does. It's
> always a good programming practice to include only those .h files that
> are really needed, inclusion of windows.h usually shows the ignorance
> and lack of knowledge of a programmer.

I've agreed with the logic and the reasons behind it for the Wine
libraries. My point was that we already avoid it more than enough in
libraries, and maybe its a good thing after far as winelib goes to
insure the apps in the programs directory always do include windows.h
so that whenever someone does a true winelib port they don't have to
make unnecessary changes just to please Wine.

Maybe someone should drop those Chromium guys a note as they seem to
include windows.h in a lot of places....

winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

[Dmitry Timoshkov]

"Steven Edwards"  wrote:
> I've agreed with the logic and the reasons behind it for the Wine
> libraries. My point was that we already avoid it more than enough in
> libraries, and maybe its a good thing after far as winelib goes to
> insure the apps in the programs directory always do include windows.h
> so that whenever someone does a true winelib port they don't have to
> make unnecessary changes just to please Wine.

Is there a specific problem you are trying to point out indirectly,
or that's just a speculation?
> Maybe someone should drop those Chromium guys a note as they seem to
> include windows.h in a lot of places....

That's a commeon practice among windows programmers, want to mail
all of them? There is a good prediction where they will tell you
to go.

winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

[Steven Edwards]

On Wed, Feb 18, 2009 at 3:16 AM, Dmitry Timoshkov
 wrote:
> Is there a specific problem you are trying to point out indirectly,
> or that's just a speculation?

I was just thinking perhaps we need a better way of making sure the
headers match up with the PSDK. I know we can do a MSVC configuration
for Windows headers and libraries for building winetest but I've not
looked at how well it works recent. The last time I attempted building
any major part of Wine with the PSDK in the include path first the
results were not very pleasing. I'll add reviewing this to the list of
hundreds of other things I mean to look at when I have the time ;)
> > Maybe someone should drop those Chromium guys a note as they seem to
> > include windows.h in a lot of places....
>
> That's a commeon practice among windows programmers, want to mail
> all of them? There is a good prediction where they will tell you
> to go.

Hehe I am sure ;)

winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

[Francois Gouget]

On Tue, 17 Feb 2009, Steven Edwards wrote:
> On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget  wrote:
> > I moved them after the windows.h include though in practice the needed
> > winnt.h has already been included by the time we include winetest.h. So
> > maybe windows.h should be nuked altogether...
>
> Conversely maybe using windows.h usage should be fixed and used more
> often. Wine is an oddball when it comes to win32 program with the
> excessive lengths it goes to, to avoid using windows.h. I am starting
> to think even avoiding it internally like we do causes more harm than
> good as far as being source compatible with MSVC.

My remark was not so much about including windows.h rather than 
winfoo.h, but about including it in winetest.h when the parent C file 
has already included the winxxx.h files it needs. That is, in Wine it 
seems we have a policy to put include statements primarily in the C 
files, rather than in private header files.

Also:
 * I don't see what depends on windows.h in winietest.h (besides my 
   newly added annotations).
 * if I remember correctly, removing this include did not cause any 
   warning or compilation error (even with my newly added annotations). 
   But maybe it's different if you compile with MinGW or MSVC (in which 
   case Wine's headers should be fixed).

winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

[Steven Edwards]

On Wed, Feb 18, 2009 at 5:20 AM, Francois Gouget  wrote:
> My remark was not so much about including windows.h rather than
> winfoo.h, but about including it in winetest.h when the parent C file
> has already included the winxxx.h files it needs. That is, in Wine it
> seems we have a policy to put include statements primarily in the C
> files, rather than in private header files.
>
> Also:
> - I don't see what depends on windows.h in winietest.h (besides my
>
> newly added annotations).
> - if I remember correctly, removing this include did not cause any
>
> warning or compilation error (even with my newly added annotations).
>   But maybe it's different if you compile with MinGW or MSVC (in which
>   case Wine's headers should be fixed).

Right, I don't disagree with the change, I was more just thinking out
loud. I agree it does not need to be in that header, I just think we
should not avoid using windows.h in the programs.

Thanks