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