By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,952 Members | 1,722 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,952 IT Pros & Developers. It's quick & easy.

system() in the absence of a command processor

P: n/a
According to 7.20.4.5 of n869, system() can report whether the host
environment has a command processor (when passed a null pointer).
Obviously, if there is a command processor, non-null string arguments
to system() are passed to it. However, the text doesn't specifically
state what occurs when there is no command processor to pass strings
to. Presumably this is nothing, but should that be obvious from the
text?

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Sep 19 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
On Tue, 19 Sep 2006, Christopher Benson-Manica wrote:
According to 7.20.4.5 of n869, system() can report whether the host
environment has a command processor (when passed a null pointer).
Obviously, if there is a command processor, non-null string arguments
to system() are passed to it. However, the text doesn't specifically
state what occurs when there is no command processor to pass strings
to. Presumably this is nothing, but should that be obvious from the
text?
Undefined behavior (by omission).

Tak-Shing
Sep 19 '06 #2

P: n/a
Tak-Shing Chan <t.****@gold.ac.ukwrote:

(WRT to invoking system() when no command processor is available)
Undefined behavior (by omission).
Ah, right. So then

#include <stdlib.h>

int main(void)
{
if( system(NULL) )
system( "echo Hello world!" );
return 0;
}

is strictly conforming, but the alternative version without the
conditional is not? That's surprising, if only because even c.l.c.
regulars do not regularly point out such before invoking system() in
examples...

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Sep 19 '06 #3

P: n/a
On Tue, 19 Sep 2006, Christopher Benson-Manica wrote:
Tak-Shing Chan <t.****@gold.ac.ukwrote:

(WRT to invoking system() when no command processor is available)
> Undefined behavior (by omission).

Ah, right. So then

#include <stdlib.h>

int main(void)
{
if( system(NULL) )
system( "echo Hello world!" );
return 0;
}

is strictly conforming, but the alternative version without the
conditional is not? That's surprising, if only because even c.l.c.
regulars do not regularly point out such before invoking system() in
examples...
Even if there is a command processor, system() might still
``behave in a non-conforming manner or to terminate'' (ISO
9899:1999, 7.20.4.6 para. 2), so it would be impossible to tell
whether your code above would invoke undefined behavior or not.

Tak-Shing
Sep 19 '06 #4

P: n/a
Christopher Benson-Manica wrote:
Tak-Shing Chan <t.****@gold.ac.ukwrote:

(WRT to invoking system() when no command processor is available)
Undefined behavior (by omission).

Ah, right. So then

#include <stdlib.h>

int main(void)
{
if( system(NULL) )
system( "echo Hello world!" );
return 0;
}

is strictly conforming, but the alternative version without the
conditional is not?
Any program that uses the system() function with a non-null argument is
probably not strictly conforming; a program that uses the system()
function to perform output certainly is not strictly conforming.

Robert Gamble

Sep 19 '06 #5

P: n/a
Tak-Shing Chan wrote:
Even if there is a command processor, system() might still
``behave in a non-conforming manner or to terminate'' (ISO
9899:1999, 7.20.4.6 para. 2), so it would be impossible to tell
whether your code above would invoke undefined behavior or not.
That sounds like undefined behavior to me!

--
Thad
Sep 20 '06 #6

P: n/a
Thad Smith <Th*******@acm.orgwrote:
Even if there is a command processor, system() might still
``behave in a non-conforming manner or to terminate'' (ISO
9899:1999, 7.20.4.6 para. 2), so it would be impossible to tell
whether your code above would invoke undefined behavior or not.
That sounds like undefined behavior to me!
It seems like it might be a bit disingenuous to simply call it
"undefined behavior", since the implementation must provide at least
some documentation for how system() will behave. Even the DS9K must
indicate that strings passed to system() will be passed to
evilCommandShell.exe for execution, although after that of course one
would be advised to seek shelter in a nuclear bunker.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Sep 20 '06 #7

P: n/a
Robert Gamble <rg*******@gmail.comwrote:
Any program that uses the system() function with a non-null argument is
probably not strictly conforming; a program that uses the system()
function to perform output certainly is not strictly conforming.
I imagine you're right, since as soon as you invoke system() you're
heading to the implementation documentation to find out what will
happen. I suppose that if one doesn't know whether the implementation
provides a command processor, one probably doesn't have any business
invoking system() anyway.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Sep 20 '06 #8

P: n/a
Christopher Benson-Manica <at***@ukato.freeshell.orgwrote:
Thad Smith <Th*******@acm.orgwrote:
Even if there is a command processor, system() might still
``behave in a non-conforming manner or to terminate'' (ISO
9899:1999, 7.20.4.6 para. 2), so it would be impossible to tell
whether your code above would invoke undefined behavior or not.
That sounds like undefined behavior to me!

It seems like it might be a bit disingenuous to simply call it
"undefined behavior", since the implementation must provide at least
some documentation for how system() will behave. Even the DS9K must
indicate that strings passed to system() will be passed to
evilCommandShell.exe for execution, although after that of course one
would be advised to seek shelter in a nuclear bunker.
Yes, but what system() actually _does_ is undefined. Or rather, what the
program called by system() does is. And it must be, because that can be
useful.
For example, you might call system("viruschecker -checkfile:
receivedexecutable"), and the user might have configured his virus
checker not to do anything by default, but always to ask him whether to
[S]kip this file, [D]elete it, or [T]erminate the calling program with
extreme prejudice. If he chooses option [T], *poof* goes your program in
a display of highly undefined - by the Standard, that is! - behaviour.

Thus, only part of what system() does - call a command shell with a
certain command line - is defined. The other part - what that command
shell does with this line - cannot, and should not even if it could, be
defined by the ISO C Standard.

Richard
Oct 3 '06 #9

P: n/a
Richard Bos wrote:
Christopher Benson-Manica <at***@ukato.freeshell.orgwrote:
Thad Smith <Th*******@acm.orgwrote:
Even if there is a command processor, system() might still
``behave in a non-conforming manner or to terminate'' (ISO
9899:1999, 7.20.4.6 para. 2), so it would be impossible to tell
whether your code above would invoke undefined behavior or not.
That sounds like undefined behavior to me!
It seems like it might be a bit disingenuous to simply call it
"undefined behavior", since the implementation must provide at least
some documentation for how system() will behave. Even the DS9K must
indicate that strings passed to system() will be passed to
evilCommandShell.exe for execution, although after that of course one
would be advised to seek shelter in a nuclear bunker.

Yes, but what system() actually _does_ is undefined. Or rather, what the
program called by system() does is. And it must be, because that can be
useful.
The behaviour is only undefined if this documentation states the
behaviour is undefined. As an example, it's possible and in some cases
even reasonable that implementation-specific documentation for system()
includes descriptions of shell built-in commands. If it does, they are
required to behave as documented.

Oct 3 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.