After a chat with Kevin I committed a middle ground which only allows
for whitespace in non-strict mode. And fixes the bug by the way.
-Alex
On Mon, Dec 15, 2008 at 4:28 PM, Alexandre Ferrieux
<ale...@gm...> wrote:
> In the absence of any response to this, I am preparing to commit the
> removal of non-strict decoding. Unless somebody objects and argues ;-)
>
> -Alex
>
> On Sat, Dec 13, 2008 at 7:59 PM, Alexandre Ferrieux
> <ale...@gm...> wrote:
>> Hi,
>>
>> While looking at
>> http://sourceforge.net/tracker/index.php?func=detail&aid=2380293&group_id=10894&atid=110894
>> I discovered that [binary decode], for all three supported encodings
>> (hex, base64 and uuencode), had a "-strict" option, meaning the
>> default was non-strict: characters outside the expected range are just
>> ignored.
>>
>> Question: what is the rationale for such "robustness" ?
>> Is there a known perturbation process that is modelled this way, which
>> would insert exclusively out-of-range chars ?
>>
>> Otherwise, it seems _very_ dangerous to ignore such errors (an
>> insertion/deletion in any of the three schemes, especially the two
>> 6bit-based, has catastrophic long-range effects).
>> Moreover, in situations where such a "controlled perturbation" is
>> expected, it is trivial for the programmer to apply a [regsub] first,
>> to filter out the offending characters.
>>
>> What about removing the non-strict pathway entirely ?
>>
>> -Alex
>>
>
|
