Subject: Re: Option to make cpp(1) not accept named pipes or devices as
To: Jim Wise <jwise@draga.com>
From: Christos Zoulas <christos@zoulas.com>
List: tech-toolchain
Date: 11/29/2004 17:55:58
On Nov 29, 5:36pm, jwise@draga.com (Jim Wise) wrote:
-- Subject: Re: Option to make cpp(1) not accept named pipes or devices as
| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1
|
| On Mon, 29 Nov 2004, Christos Zoulas wrote:
|
| >>My main concern is that this will be most often used by programs
| >>exec'ing cpp, and not all of them will be smart about allowing arguments
| >>to be part of ${CPP}, so an environment variable provides a saner way to
| >>modify cpp's behavior when called from an already-existing binary or
| >>script.
| >>
| >>There's also the concern that if users decide to use a non-basesrc cpp
| >>(as _many_ users do via pkgsrc/lang/gcc34), a new command line option
| >>will cause cpp to fail outright, while a new environment variable will
| >>not.
| >
| >The problem with the environment variable approach is that there is no
| >user feedback if the variable did something or not. With a flag the program
| >can exit with a usage message indicating to the caller that this option
| >is not supported.
|
| This is true -- on the other hand, in the case of a binary (such as
| calendar) compiled to use a new flag, the user will know that the
| requested behavior was not provided, but will be unable to get the
| binary to work, short of recompiling or of writing a wrapper script for
| cpp which strips off the offending argument.
|
| Not sure which is a more compelling argument...
It is a security issue here. I -personally - rather have it not run, than talk to a
named pipe.
christos