[IronPython] base64 bug

Alex Henderson bittercoder at gmail.com
Sun Nov 12 21:13:41 PST 2006


I tend to agree about the 1.0 Argument, the lack of a true specification for
this functionality makes these things a trial and error process, and until
the Iron python user base grows, there just simply isn't enough user
coverage to have ironed out the obvious wrinkles (or in some cases,
forgetting to iron the wrinkles in ;o) that are cropping up day to day with
this support functionality (considering how inactive this list is lately).

Just my two cents though...

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Fredrik Lundh
Sent: Monday, 13 November 2006 2:14 p.m.
To: Discussion of IronPython
Subject: Re: [IronPython] base64 bug

> >>> import base64
> >>> base64.decodestring('w/==')
> '\xc3'
>
> Now, imagine, what kind of debugging hell the above bug entailed.

on the other hand:

>>> base64.encodestring("\xc3")
'ww==\n'

so it's really the encoder that's broken.

unless I'm mistaken, the "w/==" string use the wrong padding (ones in- stead
of zeros), and the relevant RFC doesn't specify how to deal with that
situation.  as far as the specification is concerned, the decoder is free to
do whatever it wants when it gets bogus data.

(as for the "this is not 1.0" argumentation, I think you're all
overestimating how well Python is specified.  different CPython releases
aren't even com- patible with themselves on things like this, so it's a bit
naive to expect an independent implementation to be compatible at a
bug-by-bug level)

</F>
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




More information about the users mailing list