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

List:       kmail-devel
Subject:    Re: [PATCH] rewrite of KMMsgPartDlg and fixincludes rant
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2002-01-05 23:12:16
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 05 January 2002 20:22, Marc Mutz wrote:
<snip>
> See where the problem lies? Let's look at the patch as a rewrite of
> the UI and a slight increase in functionality (notice that I use 7bit
> now for diffs?). I can add a warning if the user selects 7bit and
> hits OK, and I can try to fix the issue with qp encoding of binary
> data; but let's leave it at that, please. At least for KDE3.0.
<snip>

Ok. Next try. Details (w.r.t. the provious version):
- - Less i18n calls.
- - Fix compile warnings
- - Fix truncating binary attachments when selecting QP
- - add non-GUI'ed config key for showing attachment dialog
- - add warning about 7bit "encoding"

Known bugs:
- - Whenever changing from {7,8}bit to {base64,qp}, a single actet is lost 
on the way.
What I use now is 
QByteArray body;
body.duplicate( aMsgPart->bodyDecodedBinary() )
/*set cte*/
aMsgPart->setBodyEncodedBinary( body );
This is just QCString->QByteArray and setBodyEncoded() -> 
setBodyEncodedBinary() and bodyDecoded() ->bodyDecodedBinary().

I think the problem stems from the following:
There's some workaround stuff in bodyDecodedBinary() which tries to fix 
two other functions, viz.
// do this for cases where bodyDecoded instead of bodyDecodedText
// is called. This does not warrant a trailing 0 - realloc might
// change the address. Maybe this is not really needed.
  result.resize(len+1);
  result[len] = 0;
  result.resize(len);
And when the identiy transformation is used, only mBody.size()-1 bytes 
are copied into the result:
  case DwMime::kCte7bit:
  case DwMime::kCte8bit:
  case DwMime::kCteBinary:
    len = mBody.size() - 1;
    result.resize(len);
    if (len) memcpy(result.data(), mBody.data(), len);
Also, there's the mysterious comment in kmmsgpart.h:
  /** keep it null terminated since some callers
      misuse it as a QCString. Really the callers
      should be fixed like in kmreaderwin.cpp.
      mBody should not be QCString since it can be binary. */
  QByteArray mBody;
So why don't we simply fix the callers? And why are 
setBodyEncodedBinary() and bodyDecodedBinary() not symmetric for the 
identity transformation (one does QByteArray::duplicate(), the other 
memcpy())?

If someone could explain to me the purpose of having mBody 
NUL-terminated, when we copy the data anyway on bodyDecoded*(), and 
thus could simply do
  result.resize(mBody.size()+1);
  memcpy( mBody.data(), result.data(), mBody().size() );
  result[mBody.size()] = '\0';
for returning QCStrings and
  result.resize(mBody.size());
  memcpy( mBody.data(), result.data(0, mBody.size() );
for returning QByteArrays?
What would break?

Marc

- -- 
Die sozialdemokratische Linke existiert nicht mehr. Es bleibt nur die
Frage, durch wen sie ersetzt wird: Wir haben Bush, wir haben Sharon,
Berlusconi... - ein ganz rechte Hegemonie, die keinen kümmert!
                                                         -- Ken Loach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8N4hg3oWD+L2/6DgRAvAmAJ0QkkqGRVklZ7UhXN6zP/wcbBfmnQCg+2dh
Ef+Xb3TLnrQLuYgp77mf2Zg=
=ViIE
-----END PGP SIGNATURE-----

["kmail-rewrite-kmmsgpartdlg-v2.diff.bz2" (application/x-bzip2)]
_______________________________________________
kmail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

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