bug in sscanf (scanf)?

Thread View: comp.bugs.sys5

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Martin Wilde Wed, 16 Nov 1988 18:51

#917

Author: Martin Wilde
Date: Wed, 16 Nov 1988 18:51

51 lines
1823 bytes

I have a small fragment of code that does not work on V.3.2 386 UNIX. 
The problem appears to be in sscanf (scanf).   The following fragment of
code shows the problem.


main(argc, argv)
int	argc;
char	**argv;
{
	char	optarg[1024];
	int	times;
	char	s1[40], s2[40], s3[40], s4[255];

	(void) strcpy(optarg, argv[1]);
	(void) sscanf(optarg, "%d %s %s %s %255[^\0]", &times, s1, s2, s3, s4);
	(void) printf("times = %d, s1 = %s, s2 = %s, s3 = %s, s4 = %s\n", 
			times, s1, s2, s3, s4);
}

The invocation is:

     a.out "1 10 0L 1000L 31 32 33"

The output under XENIX III and XENIX V is:

    times = 1, s1 = 10, s2 = 0L, s3 = 1000L, s4 = 31 32 33

under V.3.2 is:

    times = 1, s1 = 10, s2 = 0L, s3 = 1000L, s4 =


wheres the last string in v.3.2?

what the sscanf is trying to do for s4 is take all the characters up until
the end of string (\0) and place them in s4, but do not exceed 255 characters
(don't want core dumps).  After RTFM, there does not seem to be a problem
doing this.

Does sscanf (scanf) have a problem?  Could it be reading up until the end of
string and then returning EOF (what the manual says) and ignoring that my
stop character is the EOF?

I do have a work around to the problem, but I donot like the inconsistencies.

Thanks....

                          
                  _/_          |
 ______  __.  __  /  o ____    |  textronix!reed!littlei!zeus:martin
/ / / <_(_/|_/ (_<__<_/ / <    |

Re: bug in sscanf (scanf)?

#923

Author: Nicholas J. Simicich;?
Date: Thu, 17 Nov 1988 23:40

16 lines
1221 bytes

In article <331@zeus.hf.intel.com> martin@zeus.hf.intel.com (Martin Wilde) writes:
>  I have a small fragment of code that does not work on V.3.2 386 UNIX. 
>  The problem appears to be in sscanf (scanf).   The following fragment of
>  code shows the problem.
 .....
>  	(void) sscanf(optarg, "%d %s %s %s %255[^\0]", &times, s1, s2, s3, s4);

The bug is actually in the representation of a string in C, of course
(no flames please).   The format string is being passed to sscanf as:

"%d %s %s %s %255[^"

Since the \0 is an end of string character.  So sscanf can't interpret
what you intended.
--
Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)

Re: bug in sscanf (scanf)?

#925

Author: John Woods
Date: Fri, 18 Nov 1988 05:04

19 lines
1277 bytes

In article <331@zeus.hf.intel.com>, martin@zeus.hf.intel.com (Martin Wilde) writes:
> I have a small fragment of code that does not work on V.3.2 386 UNIX. 
> The problem appears to be in sscanf (scanf).   The following fragment of
> code shows the problem.
> 
> 
>(void) sscanf(optarg, "%d %s %s %s %255[^\0]", &times, s1, s2, s3, s4);

The problem is here.......................^^

That puts a NUL byte into the format string, which terminates it; as far as
C semantics are concerned, scanf should assume that nothing follows it.
XENIX evidently blithely went on, but System V definitely stops (and ignores
the format specification) if it sees a premature NUL byte.
-- 
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu

Science does not remove the TERROR of the Gods!

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads