Date: Wed, 1 Sep 1999 14:40:23 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Peter Restall <pete AT restall DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: sscanf() fluffs my program up !
In-Reply-To: <199908311813.TAA06418@burdock.restall.net>
Message-ID: <Pine.SUN.3.91.990901143526.3663V-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 31 Aug 1999, Peter Restall wrote:

> Hi.  I was just wondering whether there are any bugs in the 'sscanf()'
> library routine for DJGPP ?

Yes, there are; but I don't think you are hitting them, since I think 
your code is itself buggy.

>         sscanf(modedef, "%[^:]:%dx%d:%d:%d:%X:%X:%X",
>                mode->name,
>                (unsigned int *) ((u_shortint *) &mode->width),
[snip]
> /* Define the structure used for holding information about a video mode */
> typedef struct {
>         char            name[64];	/* Identification string */
>         u_shortint      width;          /* Width (in pixels) */

The member `width' is declared 16-bit unsigned short, but you read it
with a format specifier that tells sscanf its a 32-bit unsigned int.  
Therefore, sscanf will corrupt the previous member.  (You might get away 
with some of the members because GCC aligns struct members for optimum 
performance, but that's sheer luck.)

The same is true for all the other members.

To read a short, use %hd or %hX, as the case may be.