Reading QByteArray length

[lifers]

Hi, I am trying to implement a callback that receives a const QByteArray &data (https://api.kde.org/kio-transferjob.html#data).
libqt6zig requires me to implement a function signature of const fn (?*anyopaque, ?*anyopaque, [*:0]u8) callconv(.c) void (https://rcalixte.github.io/libqt6zig/#libqt6.extras-kio.libtransferjob.kio__transferjob.OnData). I suppose the data to be read comes last as a [*:0]u8.
If the data is a binary file that can contain byte 0, what's the preferred way to read its length? Thanks.

[rcalixte]

Hi! Thanks for the interest! I wasn't aware anyone had gotten deep with the KDE Frameworks so this is exciting to see!

What you'll typically do with those parameter types is pass them to std.mem.span which will return a slice where you can access the .len property. Take a look at the websocket, sonnet, or lupdate examples. These are all [*:0]const u8 examples but [*:0]u8 would be the same syntax.

Hopefully this helps!

[rcalixte]

This could be a bug in how the API translates this but I'm not sure since the steps from Zig would be the same. When processing the data from Zig, the assumption is that it will be null-terminated, otherwise how would the bound be retrievable? One thing we could do would be to make a breaking change to the API and pass the data as a libqt_string type where the len is set by the size() of the QByteArray. This would allow you to reconstruct the slice locally with the correct number of bytes. This would side-step the need to deal with a null terminator.

[rcalixte]

This is a patch from the diff that should resolve this for you:
libtransferjob.patch

You can clone the library repository and use it locally by modifying the build.zig.zon of your project to point to the clone and then applying the patch and updating your methods accordingly (change [*:0]u8 to C.libqt_string or however you've named your import). This should give you the full size as reported by the QByteArray so that you can reconstruct the full data.

On my end, I'll review the diff a little bit more before pushing it out but it looks right so far so I'm hopeful to be able to push it out soon. I'll also probably open an issue for this with your name on it. 🙏🏼

[lifers]

The patch almost works, but since C.libqt_string with members is not exported then I have to make my own type:

const raw_qt_string_ptr = @typeInfo(qt6.C.libqt_string).optional.child;
const raw_qt_string = @typeInfo(raw_qt_string_ptr).pointer.child;

fn onData(a: ?*anyopaque, _: ?*anyopaque, data: raw_qt_string) callconv(.c) void {...}

[rcalixte]

The patch almost works, but since C.libqt_string with members is not exported then I have to make my own type:

It is exported in more recent versions of the library under the C namespace here but it currently has an optional type in the definition so you currently need to use it as data.?.len and data.?.data.

If you want to patch it locally, the definition should be:

pub const libqt_string = C.libqt_string;

It could also be defined as:

pub const libqt_string = extern struct {
    len: usize = @import("std").mem.zeroes(usize),
    data: [*c]const u8 = @import("std").mem.zeroes([*c]const u8),
};

I'll include that fix in the patch. Sorry for all of the issues you're running into!

[lifers]

Much appreciated, thanks 🙏

[rcalixte]

The changes are now live if you're ready to pull the latest version. Thank you again!