Anyone had trouble with sscanf() stack usage on WinCE?

Question

Hunting down a stack overflow crash in a WinCE 5.0 C++ application, narrowed it down to a

_stscanf( astring, _T("%*s %02d\n"), &aNumber );

call made on the end of a long chain of modal dialogs, with an value of _T("LEVEL 01").

Analyzing our exception handling stack frame logging and comparing stack pointer from the last stack frame stored vers. the SP at the point the exception was thrown seemed to show an insane amount of stack usage by _stscanf()....

...sufficiently insane that I felt I needed to verify it. After a couple of days of hacking I've come up with a test routine that performs high watermark type stack usage measurements for _stscanf().

We cross-compile for two different CE targets: CE 4.2 on Renesas/Hitachi SH4 and CE 5.0 on Freescale iMX32 (ARM1136 core), as well as a Desktop Windows Emulator.

Stack Usage for _stscanf() call (approx.):

Desktop 60
CE 4.2 on SH4 9252
CE 5.0 on ARM 9280

That's right, 9K of stack on CE?!!!??

Anyone else out there come across anything like this?

Answer 1

Found the culprit.

While I'd unsuccessfully checked for swscanf() source in my CE 4.2 Platform Builder install, CE 5.0 PB does have full source for the CRT.

Line 235 of C:\WINCE500\PRIVATE\WINCEOS\COREOS\CORE\CORELIBC\CRTW32\STDIO\input.c, an 8K buffer declared as a stack variable when compiled for a UNICODE system. The non-unicode equivalent gets by with a 32 byte buffer.