bug w/file-coding & processes

Scenario: XEmacs 21.1.4 w/file-coding but not MULE (I think MULE is irrelevant, for this bug) Problem: When reading binary subprocess input (from crypt, pgp, etc.), `call-process' in code-process.el sets `coding-system-for-read' to `undecided', if `coding-system-for-read' is nil. Unfortunately, `nil' represents the "binary" coding system. If `coding-system-for-read' is `undecided' when subprocess input is read, the first few (512?) bytes are examined to determine the EOL type. Unfortunately, when reading binary input, \r (CR) is a valid character, and will make the file-coding lstream input think that CR to LF translation is required, which will corrupt the input. This is, er, "interesting"; `coding-system-for-read' needs to be `nil' (for binary input), but `call-process' insists on setting it to be `undecided'. I'm not sure what to do. Perhaps we should allow both `t' and `nil' to represent binary? In other words, these would be equivalent: (get-coding-system nil) ;; for backwards compatibility (get-coding-system t) Perhaps we should add an explicit binary coding name? Comments? In the meantime, I've kludged around the problem by not having `call-process' set `coding-system-for-read' to be `undecided'. I suspect this bug also exists in 21.2. -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.