>>> I note the specification does not forbid the handling of lines >>> longer than LINE_MAX characters. >> No, it certainly does not do that.
Yeah; like a lot of examples, recovery from error cases is allowed to be "handle it as if the limit weren't there". > It is your fault to think normal rules apply to JSON, for sure. Well, I would say, rather, that it the mistake lies in expecting normal text tools to work on newline-free JSON, or minified javascript, or other pseudo-text data without newlines). But, yeah, "they don't care any more". I have yet to find a way to configure recent Linuces so that text tools (ul, sed, etc) work in the "each octet is exactly one character" paradigm (which I want more often than they seem to think I should, even when working on Linux). For that matter I have lost track of the number of tools (Linux tools are the worst but by no means only offenders) that assume X3.64 sequences do whatever it is the program is expecting them to...and then there's recent gcc, which outputs *mis-terminated* OSCs. /~\ 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
