[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Data types for KCodecs (Re: kdenetwork/kmail)
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-12-28 14:39:15
[Download RAW message or body]

On Friday 28 December 2001 03:36, Michael Häckel wrote:
> On Thursday 27 December 2001 22:44, Dawit Alemayehu wrote:
> > IMHO you are only approaching this from the aspect of encoding/decoding
> > binary data.  There are many circumstances where I want to encode a
> > string and have the result return on a NULL terminated string.  For
> > example, basic authentication in kio_http.  As such the two current
> > functions that return a QCString are intended to reduce the number errors
> > that might occur if people are not careful when using the API.  Again
> > using the above example, if I simply convert the returned QByteArray into
> > char* and assign it to a varible the result will be corrupted since the
> > encoded text was not properly NULL terminated!
>
> Well, at least SASL authentication requires also to be able to deal with
> encoded \0 characters. KMail also needs everywhere to be able to handle
> binary data, where it is possible.
> I think, the purpose of these encoding methods is mainly to encode binary
> data and should therefore be also able to handle it.

Right.  I have no problems with that.  I know it these functions need to be able
to handle the encoding and decoding of data.  My problem with your proposal was
that I thought you wanted to remove the functions that accept/return a QCString
as these functions were important :)

> > See above why this is a bad deal if someone is not careful.  Whenever
> > you are encoding and decoding binary data, you should simply use
> >
> > static void base64Encode(const QByteArray& in, QByteArray& out, bool,
> > insertLFs = false)
> >
> > period.  Otherwise, use one of the other two functions should be used.
> > Specially, if you need a null terminated text!  I thought this was
> > straight forward enough ??
>
> The main problem is actually inconsistency like:
>
> static QByteArray  quotedPrintableDecode (const QCString & in)
>
> returns a QByteArray and the same function for base64
>
> static QCString  base64Decode ( const QCString& str )
>
> returns a QCString which results in binary data cut at the first \0
> character.

Ah... I did not write that part.  Rik did, but we can change it to follow the same
format as the other encoding and decoding functions.  Any objections Rik ?

Regards,
Dawit A.
[prev in list] [next in list] [prev in thread] [next in thread]