system() in the absence of a command processor

[Christopher Benson-Manica]

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?

 

[Tak-Shing Chan]

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

 

[Christopher Benson-Manica]

(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...

 

[Tak-Shing Chan]

(WRT to invoking system() when no command processor is available)


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

 

[Robert Gamble]

(WRT to invoking system() when no command processor is available)


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

 

[Thad Smith]

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!

 

[Christopher Benson-Manica]

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.

 

[Christopher Benson-Manica]

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.

 

[Richard Bos]

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
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

 

[Guest]

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.