Skip site navigation (1) Skip section navigation (2)

Re: Win32: Minimising desktop heap usage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Page <dpage(at)postgresql(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Win32: Minimising desktop heap usage
Date: 2007-10-23 15:30:03
Message-ID: 12474.1193153403@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Dave Page <dpage(at)postgresql(dot)org> writes:
> [ get rid of wsprintf in favor of snprintf ]

+1 for not depending on nonstandard subroutines without need.
But please note the standard locution is snprintf(buf, sizeof(buf), ...
Not sizeof() - 1.

> ! 	char		*tmppath=0;

Please use NULL not 0 ... actually, since the variable is
unconditionally assigned to just below, I'd say this should just be
"char *tmppath;".  I don't like useless initializations: if the compiler
is not smart enough to discard them then they waste cycles, and they
also increase the risk of bugs-of-omission in future changes.  If
someone were to change things around so that tmppath didn't get assigned
to in one code path, then the compiler would complain about use of an
uninitialized variable --- *unless* you've written a useless
initialization such as the above, in which case the mistake might pass
unnoticed for awhile.  So don't initialize a local variable unless
you're giving it an actually meaningful value.

> !     /*
> !      * Note: We use getenv here because the more modern SHGetSpecialFolderPath()
> !      * will force us to link with shell32.lib which eats valuable desktop heap.
> !      */
> !     tmppath = getenv("APPDATA");

Hmm, is there any functional downside to this?  I suppose
SHGetSpecialFolderPath does some things that getenv does not...

Otherwise it looks good...

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Dave PageDate: 2007-10-23 15:47:33
Subject: Re: Win32: Minimising desktop heap usage
Previous:From: Dave PageDate: 2007-10-23 15:08:20
Subject: Win32: Minimising desktop heap usage

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group