* Mark Jason Dominus <mjd@plover.com> [2012-03-04T04:53:50] > Suppose it were a fatal error to read from a multibyte-encoded string > while $/ was set to a number. What would be wrong with that? This is what I wondered when I first read the ticket. Like a bunch of the line noise variables, it can save you a bit of grief in the simplest 1992-ish case, but starts to make your (well, my) head swim when you combine it with anything else. I think the only "wrong" thing I see with your suggestion is that I'm not sure we can reliably tell what's going to give us multibyte encoded strings. I think you can put a string of layers on your fh that will take it through several encodings, and I'm not sure we have any mechanism for knowing beforehand whether we're effectively reading multibyte or singlebyte data. I think the right answer, which I believe came up already, is to put this kind of data in the layers layer. They've already got problems cooperating, but that needs fixed anyway. There's no reason I can think of to *also* require the fixing of layer cooperation to play nicely with the weird read-length behavior of the $/ variable. $/=\256 can be deprecated in the future, perhaps. If possible, only in the case where the byteishness of the layer is entirely unambiguous. -- rjbsThread Previous | Thread Next