Date: Tue, 31 Aug 1999 19:13:38 +0100
From: Peter Restall <pete AT restall DOT net>
Message-Id: <199908311813.TAA06418@burdock.restall.net>
To: djgpp AT delorie DOT com
Subject: sscanf() fluffs my program up !
Reply-To: djgpp AT delorie DOT com


Hi.  I was just wondering whether there are any bugs in the 'sscanf()'
library routine for DJGPP ?  See, I've got some code that looks like this:
        sscanf(modedef, "%[^:]:%dx%d:%d:%d:%X:%X:%X",
               mode->name,
               (unsigned int *) ((u_shortint *) &mode->width),
               (unsigned int *) ((u_shortint *) &mode->height),
               (unsigned int *) ((u_shortint *) &mode->depth),
               (unsigned int *) ((u_shortint *) &mode->flags),
               (unsigned int *) ((u_shortint *) &seg),
               (unsigned int *) ((u_shortint *) &off),
               (unsigned int *) ((u_shortint *) &mode->num));

A 'u_shortint' is defined as an 'unsigned short' (it's simply a #define to
allow for systems with different data-type sizes).

The 'mode' variable is of type 'vidmode_t' (my own type), which is defined
like:
/* Define the structure used for holding information about a video mode */
typedef struct {
        char            name[64];	/* Identification string */
        u_shortint      width;          /* Width (in pixels) */
        u_shortint      height;         /* Height (in pixels) */
        u_shortint      depth;          /* Colour depth (in bpp) */
        u_shortint      flags;          /* Mode flags */
        u_longint       absolute;       /* The absolute address of VRAM */
        u_shortint      num;            /* VESA mode number */
        u_longint       memory;         /* VRAM needed for one page */
} vidmode_t;

('u_longint's are just 'unsigned long's).  Some of the 'vidmode_t' structure
is computed from what's read by the 'sscanf()' lines.

The 'modedef' variable in the 'sscanf()' snippet is just of type 'char *', and
is what's read from a video data-file.  The strings in the data-file look
like:
	modedef:VGA 320x200 (8-bit colour):320x200:8:0:A000:0000:13

The 'modedef:' part is hacked away by my parser, and what's left is passed
through the above 'sscanf()' code.  I can read everything OK, but when it's
done, a variable (the file-handle for the video data-file, to be exact) is
corrupted !  It's address has been modified -- although how is completely
beyond me.  Now, my program doesn't exit with any error-messages (ie.
seg-fault) or anything, but when my parser tries to read another line from
the file-handle I get a premature EOF.

I've tried taking away the casts, but it still doesn't work.  I've narrowed
the problem area down to where I read the hex variables with '%X' --
everything else can be read without corrupting the file-handle, but as soon
as a single '%X' is parsed, my code pukes.  No run-time or compile-time
errors (I compiled with '-Wall -pedantic -O3 -ffast-math').

The code compiles and runs OK in Linux.  I'm not actually using DJGPP under
DOS to compile the code, but I've set up a DJGPP cross-compiler in Linux.
However, if I do compile it under DOS, the same thing happens.  Any ideas ?
Any help will be gratefully appreciated.  Thanks,


	Pete =:-)


--
/*************** [burdock] ****************/
/* ____/|   pete AT restall DOT net              */
/* \ o.O|   http://www.iirc.net/petes/    */
/*  =(_)=                                 */
/*    U                                   */
/******************************************/

/******************************* [Windoze 98] ********************************/
/* Windows 98: n.                                        (Alex Satrapa).     */
/*   64 bits (and pieces) of bugs (and fixes) and featuritis tacked on to 32 */
/*   bit extensions and a graphical shell for a 16 bit patch to an 8 bit     */
/*   operating system originally coded for a 4 bit microprocessor, written   */
/*   by a 2 bit company that can't stand 1 bit of competition, and has not a */
/*   bit of respect for their customers.                                     */
/*****************************************************************************/