>>> "\ddd", where ddd is a one, two, or three-digit octal number, shall >>> be written as a byte with the numeric value specified by the octal >>> number." >> [...] > I beg to differ: since due to this very unfortunate "variable length" > feature, your scanner has to read char by char, it can reject the > third digit since it would yield an out of range byte value.
Would it? Only if your bytes are smaller than nine bits - or if they're signed and smaller than ten bits. Is the size of a `byte' specified anywhere? If not, then the \777 -> \77 7 interpretation would parse \777 as one byte with >=10-bit bytes, two with (6-to-)8-bit bytes (9-bit bytes, it depends on whether bytes are signed). That strikes me as a relatively serious potential problem. Certainly I have heard of C implementations where `char' is the same size as short, int, and long (typically word-addressed DSPs). But I don't know whether that bears any relation to a `byte' in this sense. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
