Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!sjsca4!poffen
From: poffen@sj.ate.slb.com (Russell Poffenberger)
Newsgroups: comp.windows.ms
Subject: Re: Possible bug in tricky use of wsprintf - MSC 6.0
Message-ID: <1990Sep24.194523.1005@sj.ate.slb.com>
Date: 24 Sep 90 19:45:23 GMT
References: <6578@sugar.hackercorp.com> <57528@microsoft.UUCP> <960@metapyr.UUCP> <57612@microsoft.UUCP>
Reply-To: poffen@sj.ate.slb.com (Russell Poffenberger)
Organization: Schlumberger Technologies, San Jose, CA.
Lines: 59

In article <57612@microsoft.UUCP> matts@microsoft.UUCP (Matt Saettler) writes:
>In article <960@metapyr.UUCP> marc@metapyr.UUCP (Marc Paige - The Karate Kid ) writes:
>]In article <57528@microsoft.UUCP> kensy@microsoft.UUCP (Ken SYKES) writes:
>]>In article <6578@sugar.hackercorp.com> karl@hackercorp.com (Karl Lehenbauer) writes:
>]>>Looks like wsprintfs of the form:
>]>>
>]>>	wsprintf(outstr, "%.*s", numchars, text);
>]>>
>]>>...cause a trap.  I'll be sure in a bit.  In the meantime, beware.
>]>>-- 
>]>
>]>The * operator is not supported by wsprintf (look at the width description
>]>in the SDK.)  As a result it thinks numchars is the first part of the 
>]>string address then starts grabbing values from the bogus address.  Thus
>]>the fault.  You could get around this by writing a replacement that 
>]>handles the '*' by using wsprintf to convert the control string to a static
>]>string (replace *'s with the contents of numchar) then call wvsprintf to
>]>do the actual command.  Sloppy yes, but wsprintf is not documented as a 
>]>replacement for sprintf.  Consequently some of the features may not be
>]>provided.
>]>Ken Sykes
>]
>]WHOA!  The asterisk's got nothing to do with it!  If Karl is using the medium
>]model (as he should be :-( I hate the medium model) then the constant being
>]passed by "%.*s" is a NEAR pointer.  NEAR pointers passed to FAR pointer
>]functions cause a trap 13.  I ported a 2.11 program that had to use sprintf
>]for the error message system.  Converting all the sprintf's to wsprintf's
>]made me painfully aware of this fact.  Cast the "%.*s" to (LPSTR) and the
>]trap should be gone.  As a matter of fact, I just had to fix one of these
>]little casts that I missed the first time.  Caused "Unrecoverable Application
>]Error".  NOTE: All string arguments in the wsprintf call are LPSTR
>]               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>]and must be either cast that way or generated by GlobalAlloc.  This should
>]help.
>]
>
>The * IS the problem.  The string constant will be automatically cast
>by the compiler because the prototyp for wsprintf specifies an LPSTR.
>
>From windows.h:
>int FAR cdecl wsprintf(LPSTR,LPSTR,...);
>
>However,  Text will have to be explicitly cast if it is not an LPSTR.
>

The '*' itself is not the problem. The problem is trying to use '*' the way
most printf style calls do. The problem is in assuming that '*' meant to
look for an int variable for the precision, however wsprintf doesn't handle
that format, numchars is then being interpreted internally as the address of
a character string, and of course that won't work.

In short, wsprintf DOES NOT support the ".*" form of the precision
specification. Too bad, it can be useful. I guess you could create your own..


Russ Poffenberger               DOMAIN: poffen@sj.ate.slb.com
Schlumberger Technologies       UUCP:   {uunet,decwrl,amdahl}!sjsca4!poffen
1601 Technology Drive		CIS:	72401,276
San Jose, Ca. 95110             (408)437-5254