Syscall problem ?

Y

yezi

Hi :

I code a program by c called "inter". I have another program called
"end"

Can I code in "end " to use the syscall ( "inter") ?

If Yes , which kind of command format should I write?

thanks for any comments.

bin
 
W

Walter Roberson

I code a program by c called "inter". I have another program called
"end"
Can I code in "end " to use the syscall ( "inter") ?
If Yes , which kind of command format should I write?

I suggest you examine the documentation for the system() routine.
Pretty much all the standard says is that this will invoke
system-defined behaviour. -Usually- the string you pass into
system() is a command line that will be parsed by -something-
and the appropriate program started up.

Note: if "inter" really is a "syscall" (system call) then the
mechanisms you will need to invoke it would be operating system
dependant. Most operating systems make it difficult to add
your own system calls.
 
Y

yezi

I have another problem with that. Suppose I systemcall the function is
success, is that mean "inter" and the "end " is running simultaneously
or like the following way :

"end" ->"inter" then "end".

Thanks
 
W

Walter Roberson

I have another problem with that. Suppose I systemcall the function is
success, is that mean "inter" and the "end " is running simultaneously
or like the following way :
"end" ->"inter" then "end".

Here is the entire C89 documentation about system()

=== begin documentation ===
4.10.4.5 The system Function

Synopsis:
#include <stdlib.h>
int system(const char *string);

Description:

The system function passes the string pointed to by string to
the host environment to be executed by a command processor in an
implementation-defined manner. A null pointer may be used for
string to inquire whether a command processor exists.

Returns:

If the argument is a null pointer, the system function returns nonzero
only if a command processor is available. If the argument is not
a null pointer, the system function returns an implementation-defined
value.
=== end documentation ===

Looking at this, you can see that what happens is operating-system
specific, not defined by C. In order to know what happens on *your*
operating system, you should consult the documentation for your
operating system, or ask in a newsgroup specific to that operating
system.


The most -common- behaviour is that system() does not return
until the invoked command terminates, but that is not the only
behaviour possible and on many systems the behaviour can be modified
in an operating-system specific manner.

If you are trying to get the called program to execute at the same time
as the calling program, the mechanisms for doing that are operating
system specific, and you should consult elsewhere. In particular,
the mechanisms for Windows are considerably different than those
for Unix-like systems.
 
J

Jordan Abel

Here is the entire C89 documentation about system()

=== begin documentation ===
4.10.4.5 The system Function

Synopsis:
#include <stdlib.h>
int system(const char *string);

Description:

The system function passes the string pointed to by string to
the host environment to be executed by a command processor in an
implementation-defined manner. A null pointer may be used for
string to inquire whether a command processor exists.

Returns:

If the argument is a null pointer, the system function returns nonzero
only if a command processor is available. If the argument is not
a null pointer, the system function returns an implementation-defined
value.
=== end documentation ===

C99 adds:
| If string is not a null pointer, the system function passes the
| string pointed to by string to that command processor to be
| executed in a manner which the implementation shall document; this
| might then cause the program calling system to behave in a
| non-conforming manner or to terminate

This tells me that reasonable things for an implementation to do
are:

Block until the command finishes.

Return immediately, and then the command and your program run
concurrently.

Replace your program with the requested command.


hmm - this is really another subject, but on the same page as that:

The implementation shall behave as if no library function calls the
getenv function.

that strikes me as odd. many implementations have lots of library
functions that use environment variables, particularly for
locale-dependent stuff, or for determining the local timezone. Or
are they allowed to look in the environment as long as they don't do
it by calling getenv?
 
N

Netocrat

]
hmm - this is really another subject, but on the same page as that:

The implementation shall behave as if no library function calls the
getenv function.

that strikes me as odd. many implementations have lots of library
functions that use environment variables, particularly for
locale-dependent stuff, or for determining the local timezone. Or
are they allowed to look in the environment as long as they don't do
it by calling getenv?

They're even allowed to do it by calling getenv, so long as they behave as
though they're not.
 
W

Walter Roberson

C99 adds:
| If string is not a null pointer, the system function passes the
| string pointed to by string to that command processor to be
| executed in a manner which the implementation shall document; this
| might then cause the program calling system to behave in a
| non-conforming manner or to terminate
This tells me that reasonable things for an implementation to do
are:
Block until the command finishes.
Return immediately, and then the command and your program run
concurrently.
Replace your program with the requested command.

You missed some cases, such as system() of something that
sends a fatal signal to your program; or system() of something that
messes with your own process memory; or system() of something that
messes with kernel memory; or system() of something that crashes
taking down the system with it.
 
J

Jordan Abel

[Added crosspost to comp.std.c because that's really a more
appropriate place] [Followup-To set to comp.std.c]
]
hmm - this is really another subject, but on the same page as
that:

The implementation shall behave as if no library function calls
the getenv function.

that strikes me as odd. many implementations have lots of library
functions that use environment variables, particularly for
locale-dependent stuff, or for determining the local timezone. Or
are they allowed to look in the environment as long as they don't
do it by calling getenv?

They're even allowed to do it by calling getenv, so long as they
behave as though they're not.

Given that the standard doesn't even provide a way to e.g. "setenv"
or "putenv", what does "as if" even mean in this case? And how does
a setlocale() implementation whose return value and side effects
depend on various environment variables qualify as being 'as if not
calling the getenv function'

It seems like a silly restriction, and entirely content-free given
that the standard does not define any specifics for environment
variables.

The rationale documents are silent on this.
 
J

Jordan Abel

You missed some cases, such as system() of something that sends a
fatal signal to your program; or system() of something that messes
with your own process memory; or system() of something that messes
with kernel memory; or system() of something that crashes taking
down the system with it.

Those are matters of the behavior of the command being called, not
the implementation of the system() call itself.
 
K

kuyper

Jordan Abel wrote:
....
hmm - this is really another subject, but on the same page as that:

The implementation shall behave as if no library function calls the
getenv function.

that strikes me as odd. many implementations have lots of library
functions that use environment variables, particularly for
locale-dependent stuff, or for determining the local timezone. Or
are they allowed to look in the environment as long as they don't do
it by calling getenv?

The reason for that requirement is that "the string pointed at [by the
pointer returned by getenv()] ... may be overwritten by a subsequent
call to the getenv() function." This means that you must either
process that string completely (whatever that means for your program),
or you must copy that string to a suitable location, before making
another call to getenv().

The requirement that standard library function calls must act as though
they don't call getenv() means that you can call as many of those
function as you want before saving the result of the getenv() call.
This is particular important when you consider all of the typical uses
of an environment variable. At a minimum, you might want to call
strlen() to find out how long the string is, and members of the
malloc() family to allocate enough space to make a copy of it. If the
string is or contains a file name, it's convenient to know that you can
safely pass it to an fopen() call without worrying about the string
buffer being overwritten.

The requirement can be dealt with in a simple fashion: any environment
strings needed by other standard library functions can be retrieved by
an implementation-specific function similar to getenv(), but which uses
a different buffer to store the string values. Another alternative is
that the standard library functions could save a copy of the current
contents of the buffer, and then restore them from that copy before
returning. This gets a little tricker for the functions which use
callbacks, such as bsearch() and qsort().
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top