HEAP_ZERO_MEMORY was: Re: Prevent passing uninitialised string to WARN

[Uwe Bonnes]

> > > > > "Medland," == Medland, Bill  writes:

Medland,> Bill Medland ([e-mail]) Prevent trying to handle
    Medland,> uninitialised memory as a string.

Medland,> Index: wine/loader/module.c
    Medland,> ===================================================================
    Medland,> RCS file: /home/wine/wine/loader/module.c,v retrieving
    Medland,> revision 1.144 diff -u -r1.144 module.c ---
    Medland,> wine/loader/module.c 2001/12/20 00:19:42 1.144 +++
    Medland,> wine/loader/module.c 2002/01/17 13:45:52 @@ -1379,6 +1379,7 @@

Medland,>  	filename = HeapAlloc ( GetProcessHeap(), 0, MAX_PATH + 1 );
    Medland,> if ( !filename ) return NULL; 
    Medland,> + *filename = 0; /* Just in case

Wouldn't  HEAP_ZERO_MEMORY be a better argument to HeapAlloc then 0?

This would apply to many places.

Bye

[Francois Gouget]

On Thu, 17 Jan 2002, Uwe Bonnes wrote:
> > > > > > "Medland," == Medland, Bill  writes:
> Medland,> Bill Medland ([e-mail]) Prevent trying to handle
> Medland,> uninitialised memory as a string.
>
> Medland,> Index: wine/loader/module.c
> Medland,> ===================================================================
> Medland,> RCS file: /home/wine/wine/loader/module.c,v retrieving
> Medland,> revision 1.144 diff -u -r1.144 module.c ---
> Medland,> wine/loader/module.c 2001/12/20 00:19:42 1.144 +++
> Medland,> wine/loader/module.c 2002/01/17 13:45:52 @@ -1379,6 +1379,7 @@
>
> Medland,>  	filename = HeapAlloc ( GetProcessHeap(), 0, MAX_PATH + 1 );
> Medland,> if ( !filename ) return NULL;
> Medland,> + *filename = 0; /* Just in case
>
> Wouldn't  HEAP_ZERO_MEMORY be a better argument to HeapAlloc then 0?

I like the '*filename = 0' solution better as HEAP_ZERO_MEMORY would
overinitialize the buffer (wasting CPU time and memory bandwidth).

In fact I would like the following even better :-)

*filename = '\0';

(assuming filename is a char*)
   But that's just a question of style.

--
Francois Gouget         [e-mail]        http://fgouget.free.fr/
      Broadcast message : fin du monde dans cinq minutes, repentez vous !

[Bill Medland]

"Uwe Bonnes"  wrote in message
news:[e-mail]...
> > > > > > "Medland," == Medland, Bill  writes:
> Medland,> Bill Medland ([e-mail]) Prevent trying to handle
> Medland,> uninitialised memory as a string.
>
> Medland,> Index: wine/loader/module.c
> Medland,>

===================================================================
> Medland,> RCS file: /home/wine/wine/loader/module.c,v retrieving
> Medland,> revision 1.144 diff -u -r1.144 module.c ---
> Medland,> wine/loader/module.c 2001/12/20 00:19:42 1.144 +++
> Medland,> wine/loader/module.c 2002/01/17 13:45:52 @@ -1379,6 +1379,7

@@
> Medland,>  filename = HeapAlloc ( GetProcessHeap(), 0, MAX_PATH + 1 );
> Medland,> if ( !filename ) return NULL;
> Medland,> + *filename = 0; /* Just in case
>
> Wouldn't  HEAP_ZERO_MEMORY be a better argument to HeapAlloc then 0?
>
> This would apply to many places.
> Bye
>
> Uwe Bonnes                [e-mail]
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. [phone] -------- Fax. [phone] ----------

Take your pick.
The fix is almost certainly fixing something that is only theoretically
possible and will never happen.  As far as I am concerned all I want is to
ensure that filename is a valid string, in case it gets passed to the
snprintf or whatever sits below WARN before the core code actually puts a
string in it.  Setting the first character is good enough for that.  It
ought to be faster too.

(What this is hiding, of course, is the fact that Bill Medland doesn't
really know how to program in Windows and didn't know about
HEAP_ZERO_MEMORY).

I think you are right that there are a lot of places where we are not
initialising memory that we ought to.  That then gets into the whole subject
of defensive programming and just how much we should do it.  I noticed a
thing in the New York Times today suggesting that Microsoft are possibly
going to be a little more proactive in the area of robust coding.

Anyway, thanks for the education ;-)

Bill