> Well, ok, but that still does not explain why you cast one "check" to
> (unsigned char) leaving others untouched. QByteArray::operator[] also returns
> a _signed_ char. So what makes you think those chars will always be <= 127 ?
>
Um, yes, you're right. I missed code that reads tar files. The
> > Can you point to some of those checks? I've looked through the code again
> > and found nothing related to QString. There are only some of them related
> > to QByteArray.
>
> But why do you think QByteArray checks are not affected?
Because QByteArray is intended to store raw bytes [1], while
> What I'm concerned about is that your patch may not be complete. There are
> more similar "checks" in ktar.cpp. As I absolutely have no idea how tar works,
> this will take time to handle properly (or hopefully upstream responds in the
> meantime). Thanks for forwarding the bug.
Can you point
> This though is not totally clear to me. On the major architectures,
> char is signed, so I would assume that a chksum error in this area
> should have hit a lot of people already? Given that int is signed by
> default I wonder if this is the proper approach and it shouldn't rather
> be cast to si
Package: libkio5
Version: 4:4.4.5-3.1
Severity: grave
Tags: patch
Justification: causes non-serious data loss
I tried to create tar by KBackup program and found
truncated names of my files in .tar. KBackup uses
KTar class for writing tar files and that class
have broken UTF-8 support, it seems.
F
5 matches
Mail list logo
