<div dir="ltr">On Tue, Mar 10, 2015 at 7:39 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
<br>
On 03/10/2015 04:10 AM, Andrea Canciani wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
From: Andrea Canciani <<a href="mailto:ranma42@gmail.com" target="_blank">ranma42@gmail.com</a>><br>
<br>
On MacOSX, the sed utility errors out when parsing non-UTF8<br>
files.<br>
</blockquote>
<br></span>
Holy crap! Sorry but I have been ranting against this sort of stupidity for years, but nobody seems to pay attention.<br>
<br>
Note that it is impossible to make a sed script that will correct the non-UTF-8 into UTF-8. Therefore the authors are actually HURTING the transition to UTF-8, not helping as they so foolishly believe.<br>
<br>
The Apple or BSD engineers who wrote this are idiots.<br></blockquote><div><br></div><div>To be fair, 'sed' only defaults to UTF-8 if the environment does not explicitly define the encoding.<br></div><div>If you build the testsuite with LC_ALL=C in your environment, there is no error (and I expect that in this case the stream is treated as simple sequence of bytes).<br></div><div>Unfortunately the default on MacOSX seems to be no explicit LC_ALL, which causes only a small subset of the tests to be compiled in unless you remember to edit your environment :\<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Text stream reading should NEVER NEVER NEVER throw an error on any unexpected bytes, and should be able to deal with any byte pattern and distinguish it from any different byte pattern.<br>
<br>
The best way to do this is to stop using UTF-16 or UTF-32 internally, and just deal with UTF-8 directly. It is not hard at all. You can parse a UTF-8 stream in both directions with very little code, even a stream containing errors. Don't panic, and realize that sed and every other text tool has been dealing with words and lines and sentences and paragraphs for 50 years despite the horrific fact that they are "variable length" and will have NO trouble dealing with variable length "characters". And you may even start to handle combining characters correctly once you get over the fixed-size delusion.<br>
<br>
If you really can't stand that, please make your converter from UTF-8 to internal just turn error bytes into a replacement character (a different one for each of the 128 possible error bytes, the high bit is set on all of them). For UTF-16 turn them into 0xDC80..0xDCFF, which are nice because they are technically invalid UTF-16. For UTF-32 you have the option of turning them into some value greater than 0x10FFFF so you can distinguish them from correctly-encoded 0xDC80..0xDCFF.<br>
<br>
In any case fixing text files so they are UTF-8 is a good idea so this is a good patch. But it would be nice to not be forced by bugs to do this.<br>
</blockquote></div><br></div><div class="gmail_extra">Another good patch is one that causes "make" to fail if 'sed' fails... I will try to do that soon(ish)<br><br></div><div class="gmail_extra">Andrea<br></div></div>