Xref: utzoo comp.unix.questions:13233 comp.unix.wizards:15901
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!cadre!pitt!cisunx!jcbst3
From: jcbst3@cisunx.UUCP (James C. Benz)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: system() --- the C function from hell?
Keywords: system, unix, question, does anyone use this line?
Message-ID: <17891@cisunx.UUCP>
Date: 2 May 89 15:42:15 GMT
References: <1827@uop.edu>
Reply-To: jcbst3@unix.cis.pittsburgh.edu (James C. Benz)
Organization: Univ. of Pittsburgh, Comp & Info Sys
Lines: 120


In article <1827@uop.edu> jeff@uop.edu (Jeff Ferguson) writes:
>
>	Hi kids,
>
>	The system() call seems to wreak havoc with integer variables.
>I have the following code:
>
>/****** Code *******/
>
>int lowp, hip;
>...
>scanf("%d", &hip);
>scanf("%d", &lowp);
>sprintf(str, "/bin/mkdir directory");
>system(str);
>...
>
>/**** End Of Code ****/
>
>I printed the values of LOWP and HIP before the system() call, and
>everthing was pee-chee (like the folder).  I print them out after
>the call and the values have been blown to high Heaven: before they
>were both 3, while after system(str) they are in the tens of millions.
>
>OK, people, for $200 and the chance at the Chevy Sprint Turbo --- my
>question is this: what is happenning here an how can it be fixed?  I
>am stymied.

You don't mention how you declare the variable str, so I can't be sure at this,
but for a Sprint Turbo----

My experience with zapped int variables has nothing to do with the system call,
but rather with the length of string variables being declared too short to hold
what you try to stuff into them.  Are you sure the str size is long enough to
hold what you sprintf into it?  Is str declared directly before the two ints?
Sprintf and other string routines in (ATT Sys V) standard C don't know how long
the declared length of a string is, and will quite happily zap whatever is in
their way.  Also, I wouldn't trust scanf for anything.  So where can I pick up
the keys?
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: system() --- the C function from hell?
Summary: 
Expires: 
References: <1827@uop.edu>
Sender: 
Reply-To: jcbst3@unix.cis.pittsburgh.edu (James C. Benz)
Followup-To: 
Distribution: 
Organization: Univ. of Pittsburgh, Comp & Info Sys
Keywords: system, unix, question, does anyone use this line?

In article <1827@uop.edu> jeff@uop.edu (Jeff Ferguson) writes:
>
>	Hi kids,
>
>	The system() call seems to wreak havoc with integer variables.
>I have the following code:
>
>/****** Code *******/
>
>int lowp, hip;
>...
>scanf("%d", &hip);
>scanf("%d", &lowp);
>sprintf(str, "/bin/mkdir directory");
>system(str);
>...
>
>/**** End Of Code ****/
>
>I printed the values of LOWP and HIP before the system() call, and
>everthing was pee-chee (like the folder).  I print them out after
>the call and the values have been blown to high Heaven: before they
>were both 3, while after system(str) they are in the tens of millions.
>
>OK, people, for $200 and the chance at the Chevy Sprint Turbo --- my
>question is this: what is happenning here an how can it be fixed?  I
>am stymied.

You don't mention how you declare the variable str, so I can't be sure at this,
but for a Sprint Turbo---- AND $200 (I'll settle for the bucks)

My experience with zapped int variables has nothing to do with the system call,
but rather with the length of string variables being declared too short to hold
what you try to stuff into them.  Are you sure the str size is long enough to
hold what you sprintf into it?  Is str declared directly before the two ints?
Sprintf and other string routines in (ATT Sys V) standard C don't know how long
the declared length of a string is, and will quite happily zap whatever is in
their way.  Also, I wouldn't trust scanf for anything.  So where can I pick up
the keys?











line fodder












and more line fodder
-- 
Jim Benz 		     jcbst3@unix.cis.pittsburgh.edu     If a modem 
University of Pittsburgh					 answers,
UCIR			     (412) 648-5930			 hang up!