> > or implicitly (locale) command them not be. > > Not fine without a warning. This is 'action at a distance' (this is the > same reason un'local'ized usage of the 'special' variables is nearly
On that we can agree, kind of-- I find the *whole* locale system to be a Bad Idea (tm) (not just any UTF-8 parts of it). Locales are *all* about action-at-a-distance. > always a Bad Idea (tm)). It causes breakage that can be hard to find the > cause of. Perl needs a mandatory warning if the locale changes my > filehandles to text mode and I haven't made some kind of _explicit_ > declaration that I want that behavior to happen. > > The change is of a bad 'type': An incompatible change in Perl semamtics > without so much as a warning being issued by either the compiler or the > runtime - except to make the code fall over dead many lines away from the > actual breakage. If the string is invalid UTF8, why didn't Perl complain > _when I read it_ instead of dozens of lines away when I tried to use that > string for something else? That is _broken_. See below. > > If you try to push Unicode (data marked as UTF-8, such as characters > > beyond 255) on such a filehandle, you'll get 'Wide character' warning. > > But it _reads_ binary data through a UTF8 layer silently. No warnings. Try > the code I posted on an actual jpg file with UTF-8 local set in the > environment. The first complaint is when the code falls over dead in the > 'jpegsize' sub - many lines of code away from the <fh> read. I think now I reached your page. I have to think more about this, though, not to make the checking at the point of reading for example unreasonably slow. And I'll be rather Internet connectivity challenged in the coming weeks, so please be patient. -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
