Using sscanf in an interrupt routine

Mike Bova

unread,

Mar 4, 1997, 3:00:00 AM3/4/97

to

Hi,
I am porting (Trying to port) a C language program from Borland to
Microsoft
C V 1.52. The code has an interrupt routine that uses sscanf. The
software
works fine when compiled under Borland Turbo C but gives a stack
overflow
as soon as the interrupt uses the sscanf when compiled using MSVC. I
found
that using STACKS in config.sys would make the overflow problem go away
but only when I used STACKS 64,512. I also found that increasing my C
programs stack size to 30000 allowed me to reduce the stacks statement
to around 32,512, see
http://www.microsoft.com/kb/articles/q58/4/36.htm.

The last thing I did was to create and use my own stack when entering
the interrupt routine since I suspected that the sscanf uses quite a lot
of
the stack. Using this method I was able to remove the STACKS entry
from my config.sys and also reduce the stack size in my program
to a more reasonable size of 10k (if you call that reasonable).

Have I solved the problem or just masked it by moving things around ?
I have done a quick binary dump of the new stack and it does not
seem like very much of it is being used. Is using an sscanf in an
interrupt
routine allowed even if it is being used in the mainline ? If not, does
anybody have any suggestions other than writing my own subset of sscanf.
Thanks in advance !
Mike

--
----------------------------------------------------------------------------
Mike Bova IC/VPRB/DRL Email:
Mike...@crc.doc.ca
Communications Research Centre Voice: (613) 998-2911
3701 Carling ave Ottawa Ont. Canada K2H 8S2 Fax: (613) 990-7987

Paul D. DeRocco

unread,

Mar 4, 1997, 3:00:00 AM3/4/97

to

Mike Bova wrote:
>
> Hi,
> I am porting (Trying to port) a C language program from Borland to
> Microsoft
> C V 1.52. The code has an interrupt routine that uses sscanf. The
> software
> works fine when compiled under Borland Turbo C but gives a stack
> overflow
> as soon as the interrupt uses the sscanf when compiled using MSVC. I

Another thing you might try is rewriting it not to use sscanf. I have a
hard time imagnining what an interrupt handler could be doing that
actually needs the fairly high-level functionality of sscanf.

--

Ciao,
Paul D. DeRocco

nico

unread,

Mar 5, 1997, 3:00:00 AM3/5/97

to

All other INT's (sscanf is most certanly based on a INT 21 ) are
banned in interrupt handlers ( reentry is not allowed in dos int's )
Better go directly to keyboard for getting input

As already said wonder what a interrupt handler is doing with a sscanf
????????

Geoffrey Levand

unread,

Mar 6, 1997, 3:00:00 AM3/6/97

to

I was asking for something specific and perfect for my city,
Whereupon lo! upsprang the post of Mike Bova <Mike...@crc.doc.ca>:

>I am porting (Trying to port) a C language program from Borland to
>Microsoft
>C V 1.52. The code has an interrupt routine that uses sscanf. The

...

I'm almost certain sscanf() is non-reentrant. The source code is at
<ftp.microsoft.com> in the softlib directory, so you can check it out
yourself. But I doubt that this is the cause of your stack overflow.
It would most likely just cause data corruption in your main program.

You don't say how you know the stack overflows, but if there's a
message on the screen then that's your problem. That message comes
from MSC's stack checking routine. You can't use stack checking in an
isr. Check the MSC documentation on __interrupt. Put any code
executed in your isr as below.

#pragma check_stack(off)
... isr stuff
#pragma check_stack()

MSC's debug libraries probably use stack checking, so that would cause
a stack overflow when sscanf() is called. One way to see is to set a
breakpoint just before sscanf(). Use mixed source and assmbly in the
source window, and see if you single step into the stack check
routine.

Your isr might be taking longer to execute than the interval it is
called at. If you enable interrupts inside your isr, this would cause
a stack overflow.

G. Levand

Keith A Goatman

unread,

Mar 12, 1997, 3:00:00 AM3/12/97

to

nico <mor...@alpes-net.fr> wrote in article <331dbccf...@news.internetsat.com>:

>All other INT's (sscanf is most certanly based on a INT 21 ) are
>banned in interrupt handlers ( reentry is not allowed in dos int's )
>Better go directly to keyboard for getting input

It is _very_ unlikely that sscanf is based on int 21h, it processes a
string rather than a file stream. I think you're thinking of scanf/fscanf.

--
Keith A Goatman Medical Physics Department
email: K.A.G...@Sheffield.ac.uk Northern General Hospital, Sheffield