Is Sprintf() recursion-safe?

[vefatica]

I have a rudimentary plugin variable function

@DU[dir[,flag(s)]] = disk use; flags: R = recurse, A = allocated

It works, for example,

v:\> echo %@du[c:\,r]
7790035966

But when I change wsprintf() to Sprintf() in two locations in ProcessDirectory() (code below), it gives garbage, like

v:\> echo %@du[c:\,r]
8971340599845407408

Sprintf() has always been good to me and this kind squirrely error is usually my fault. But I can't find anything wrong! Help! Code below (DU.CPP attached as DU.TXT). It says you can't attach CPPfiles!!!!!!!!

// globals
DWORD dwClusterSize = 0;
ULONGLONG ullTotalClusters = 0, ullTotalBytes = 0;

VOID ProcessDirectory( WCHAR *pDirName, BOOL bRecurse )
{
ULONGLONG ullFileSize;
WIN32_FIND_DATA wfd;
WCHAR szFindRoot[MAX_PATH];
Sprintf(szFindRoot, L"%s*", pDirName);
HANDLE hFind = FindFirstFile(szFindRoot, &wfd);

if ( !hFind ) return;

do
{
if ( bRecurse && wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY )
{
if ( wfd.cFileName[0] != L'.' && !(wfd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) )
{
Sprintf(szFindRoot, L"%s%s\\", pDirName, wfd.cFileName);
ProcessDirectory(szFindRoot, bRecurse);
}
}
else // not a directory
{
ullFileSize = (ULONGLONG) wfd.nFileSizeHigh * 0x100000000I64 + wfd.nFileSizeLow;
ullTotalBytes += ullFileSize;
ullTotalClusters += ( (ullFileSize + dwClusterSize - 1) / dwClusterSize );
}
}
while ( FindNextFile(hFind, &wfd) );

FindClose(hFind);
}

 

[Steve Fabian]

vefatica wrote:
| I have a rudimentary plugin variable function
|
| @DU[dir[,flag(s)]] = disk use; flags: R = recurse, A = allocated
| ...

Is this supposed to do what @filesize[] (which allows /S for tree search,
and ",,a" for "allocated") already does?

| Sprintf() has always been good to me and this kind squirrely error is
| usually my fault. But I can't find anything wrong! Help! Code
| below (DU.CPP attached as DU.TXT). It says you can't attach
| CPPfiles!!!!!!!!

By the time I received this post by email nothing was attached, only a URL,
which required logging into the web forum.

I know nothing about Sprintf (only about sprintf), so I cannot help...
--
Steve

 

[vefatica]

On Mon, 23 Feb 2009 21:59:56 -0600, Steve Fábián <> wrote:

|vefatica wrote:
|| I have a rudimentary plugin variable function
||
|| @DU[dir[,flag(s)]] = disk use; flags: R = recurse, A = allocated
|| ...

|Is this supposed to do what @filesize[] (which allows /S for tree search,
|and ",,a" for "allocated") already does?

I didn't know that ... no use in reinventing the wheel.

|| Sprintf() has always been good to me and this kind squirrely error is
|| usually my fault. But I can't find anything wrong! Help! Code
|| below (DU.CPP attached as DU.TXT). It says you can't attach
|| CPPfiles!!!!!!!!

|By the time I received this post by email nothing was attached, only a URL,
|which required logging into the web forum.

|I know nothing about Sprintf (only about sprintf), so I cannot help...

It's exported by TakeCmd.dll. C's sprintf() (swprintf() for Unicode) takes up a
good 10K. Sprintf() and USER32.DLL's wsprintf() are called dynamically so they
don't take up room in the EXE/DLL.

Does your use of "|" to quote quotes avoid vBulletin's unsightly quote tags in
emails?
--
- Vince

 

[Steve Fabian]

vefatica wrote:
| On Mon, 23 Feb 2009 21:59:56 -0600, Steve Fábián <> wrote:
|
|| vefatica wrote:
||| I have a rudimentary plugin variable function
|||
||| @DU[dir[,flag(s)]] = disk use; flags: R = recurse, A = allocated
||| ...
|
|| Is this supposed to do what @filesize[] (which allows /S for tree
|| search, and ",,a" for "allocated") already does?
|
| I didn't know that ... no use in reinventing the wheel.

Glad to save you the trouble. Rex' software is getting so rich in features
that nobody but Rex can keep track of all of them, yet we still keep asking
for more...

||| Sprintf() has always been good to me and this kind squirrely error
||| is usually my fault. But I can't find anything wrong! Help! Code
||| below (DU.CPP attached as DU.TXT). It says you can't attach
||| CPPfiles!!!!!!!!
|
|| By the time I received this post by email nothing was attached, only
|| a URL, which required logging into the web forum.
|
|| I know nothing about Sprintf (only about sprintf), so I cannot
|| help...
|
| It's exported by TakeCmd.dll. C's sprintf() (swprintf() for Unicode)
| takes up a good 10K. Sprintf() and USER32.DLL's wsprintf() are
| called dynamically so they don't take up room in the EXE/DLL.

Makes sense. Even with today's common memory sizes, waste is waste, and
better written (and esp. better DESIGNED) software can substantially
increase performance. It is far too common nowadays for programs to trade
simplicity of coding for performance.

| Does your use of "|" to quote quotes avoid vBulletin's unsightly
| quote tags in emails?

If you refer to the "--- quote (originally by ...) ---" style, the answer is
(unfortuantely) NO. It is a display option in Thunderbird that is visually
much more pleasing to me than repeated > characters. A freeware product,
OE-QuoteFix emulates it in Outlook Express. I have been using it for many
years.

BTW, I stopped using Thunderbird, due to its repeated downloading of
long-ago downloaded newsgroup articles (from true NGs).
--
Steve

 

[rconn]

vefatica wrote:

> I have a rudimentary plugin variable function
>
> @DU[dir[,flag(s)]] = disk use; flags: R = recurse, A = allocated
>
> It works, for example,
>
> v:\> echo %@du[c:\,r]
> 7790035966
>
> But when I change wsprintf() to Sprintf() in two locations in ProcessDirectory() (code below), it gives garbage, like
>
> v:\> echo %@du[c:\,r]
> 8971340599845407408
>
> Sprintf() has always been good to me and this kind squirrely error is usually my fault. But I can't find anything wrong! Help! Code below (DU.CPP attached as DU.TXT). It says you can't attach CPPfiles!!!!!!!!

Sprintf is definitely recursion-safe; if it weren't, precious little in
TCMD / TCC would work.

You shouldn't be using GetDiskFreeSpace; use GetDiskFreeSpaceEx.

You should clear out the WIN32_FIND_DATA struct before calling
FindFirstFile/FindNextFile; I wouldn't trust Windows to be clearing out
the high part of the file size.

I also don't trust your ulFileSize assignment; I'd either do something
like this:

LONGLONG fsize = fdata.nFileSizeHigh*((LONGLONG)ULONG_MAX + 1) +
fdata.nFileSizeLow;

or this:

dir->ulSize = dir->dwFileSizeHigh;
if ( dir->ulSize )
dir->ulSize *= (__int64)4294967296.0;
dir->ulSize += dir->dwFileSizeLow;

Rex Conn
JP Software

 

[vefatica]

On Thu, 26 Feb 2009 09:02:52 -0600, rconn <> wrote:

|You shouldn't be using GetDiskFreeSpace; use GetDiskFreeSpaceEx.

I don't see how to get the cluster size from the information provided by
GetDiskFreeSpaceEx.
--
- Vince