[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > All input parity checking is done by term itself, and the device > should just do none (or at least provide a way to turn it off).
Oh, things aren't quite right here yet. First, note that the arg to input_character is a full int. A simple char is not enough; if the incoming byte has 8 bits and parity, then that's 9 bits and it won't fit. There is nothing in serial communication to distinguish parity from an extra bit. If the user sets INPCK, then the last bit coming in is parity, and gets checked. If ISTRIP is set, then any parity bit is stripped. What the lower half should do is treat the parity bit like just another bit and provide it as part of the data. Because it can't distinguish a parity bit from a data bit, it can't treat it as anything but the most significant bit of the result. If a short byte comes in, it should pad with zeros. If a long byte comes in, it should probably take the first N bits as data, and make the rest zeroes. Both these solutions result in the parity bit as seen by munge.c to be zero; that means that at least it won't break the no-parity case. It's not important what exactly happens here, however, and there may well be some hardware which simply treats all such cases as framing errors. Then, munge.c needs to DTRT. Unfortunately, the current code is buggy in that it always assumes that the parity bit is at 0x80. To fix the bug, reference needs to be made to the current byte side by the relevant checks in checkoddpar, checkevenpar, and the ISTRIP handling. Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
