Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20020413125703.021ef950@localhost>
Date: Sat, 13 Apr 2002 13:20:25 -0500
To: dev@apr.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Unix missing fd 0..2, Win32 service missing stdin/out/err
  handles
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

A suggestion to implement in apr_app_initialize, but first some background.

Without harming apr_initialize(), which should continue to be useful
for initializing apr in a non-apr application (e.g. a mod_jk connector built
with apr, that is written for Apache 1.3), I had started an apr_app_initialize
a while back.

One paragraph of background; I created apr_app_initialize primarily to allow
us to use the apr signals API... if we detect the app is running in a console,
we can set up the Windows console API in the signal schema.  If we detect
we are running 'as a service', we can set up the Windows SCM context
immediately, and when apr_daemonize is invoked, we can report 'started'.
We also use apr_app_initialize on Win32 to transform our Unicode input
(command line args and the environment table) into utf-8 internal encoding.
So far, so simple [yet I haven't had three days to put the signals together.]

Back to the purpose of this post;

Because third party libraries have a nasty habit of dropping messages out
to stderr or stdout... and will sometimes even poll stdin (think passphrases
or other bits in encryption libraries, etc) ... it is rather dangerous for 
-our-
applications to ever use fd 0..2.  Sure, you can chalk it up to a bug in the
caller, but imagine if 'by chance' we open up an sdbm as fd 2.  Another
library prints something to stderr and bang ... database is corrupted.

On the Win32 side, same goes for FILE *'s stdin, stderr and stdout, for
the low level 'fd's 0..2 (not really fd's as unix knows them, but the clib's
table of Win32 handles), and the Win32 standard handles.  Win32 services
have -no- STD handles, even when they are command line apps.

So, on the unix side, within apr_app_initialize, I suggest calling
fopen("/dev/null", ) until it returns an fd >2.  On the Win32 side, I suggest
calling GetStandardHandle() and filling in any missing stdhandles with
the appropriate FILE*'s fd's handle after opening 'NUL' in the clib, so all
three bases are covered.  If we end up with an fd >2, then we immediately
close that last /dev/null file and go on.

Does this make good sense?

Bill