Quelqu'un a-t-il eu des problèmes avec l'utilisation de la pile sscanf() sur WinCE?

Question

chasse vers le bas d'un choc dans une application WinCE 5.0 C++ de débordement de pile, réduit à un

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

appel fait à la fin d'une longue chaîne de boîtes de dialogue modales, avec une valeur de _T ("NIVEAU 01").

Analyse de notre journal de trames de pile de gestion des exceptions et comparaison du pointeur de pile à partir de la dernière image de pile stockée. le SP au moment où l'exception a été lancée semblait montrer une quantité folle d'utilisation de la pile par _stscanf() ....

... suffisamment fou que je sentais que j'avais besoin de le vérifier. Après quelques jours de piratage, je suis venu avec une routine de test qui effectue des mesures d'utilisation de la pile de type filigrane haute pour _stscanf().

Nous effectuons une compilation croisée pour deux cibles CE différentes: CE 4.2 sur Renesas/Hitachi SH4 et CE 5.0 sur Freescale iMX32 (noyau ARM1136), ainsi qu'un émulateur Windows Desktop.

utilisation de la pile pour _stscanf() appel (approx.):

bureau 60
CE 4.2 sur SH4 9252
CE 5.0 sur ARM 9280

Ce qui est juste, 9K de la pile sur CE ?! !! ??

Y a-t-il quelqu'un d'autre qui rencontre quelque chose comme ça?

Answer 1

J'ai trouvé le coupable.

Alors que j'avais vérifié sans succès la source swscanf() dans mon installation CE 4.2 Platform Builder, CE 5.0 PB a une source complète pour le CRT.

Ligne 235 de C: \ WINCE500 \ PRIVATE \ WINCEOS \ COREOS \ CORE \ CORELIBC \ CRTW32 \ STDIO \ input.c, un tampon de 8 Ko déclaré comme variable de pile lorsqu'il est compilé pour un système UNICODE. L'équivalent non-unicode obtient avec un tampon de 32 octets.