This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Cpp patches for VMS
- From: "Douglas B. Rupp" <rupp at gnat dot com>
- To: "Zack Weinberg" <zack at codesourcery dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 Nov 2001 15:11:04 -0800
- Subject: Re: Cpp patches for VMS
----- Original Message -----
From: "Zack Weinberg" <zack@codesourcery.com>
To: "Douglas B. Rupp" <rupp@gnat.com>
Cc: <gcc-patches@gcc.gnu.org>
Sent: Monday, November 19, 2001 2:58 PM
Subject: Re: Cpp patches for VMS
|
| Augh yuck. Why can't it just use mailboxes? LIB$SPAWN purports to
| let you redirect the input and output of the subprocess...
|
| Incidentally, you might know this - the manuals give the strong
| impression that DCL is capable of loading and executing a new "image",
| then regaining control when it exits, *without* creating a subprocess
| to do it in. I can't find any routines that cause that to happen from
| the compiled-program level, but it must be possible. It would be a
| good idea to make pexecute.c do that instead of trying to use
| fork/exec. (Weird, why does pexecute.c even compile? It wants fork,
| but the CRTL only has vfork.)
|
| zw
You can load and execute a new image in the same process, but you can't regain control
again. I'm trying to remember the routine that does this, its a left over from the old
days before virtual memory, and was used to chain programs together to limit memory
use by the text segment.