Sure, I can add the example program. However, it's still not working, I need to get some time to try to debug it. NVM that, I screwed converting a PNG to JPEG and didn't notice it... The program now reports the result as "valid". Still have to write a function to get the data out, but I can add the program here.

RE CMakeLists.txt I can try too, but I'm not familiar with CMake so it'd probably be easier and faster if you added one yourself ^^'

BTW is it worth adding NULL checks to input arguments?

Sure, I can add the example program. However, it's still not working, I need to get some time to try to debug it. NVM that, I screwed converting a PNG to JPEG and didn't notice it... The program now reports the result as "valid". Still have to write a function to get the data out, but I can add the program here.

In that regard: note that I added a commit changing the stbi usage to be in line with the other tools. This would then also work for png images.

RE CMakeLists.txt I can try too, but I'm not familiar with CMake so it'd probably be easier and faster if you added one yourself ^^'

The following should work as a minimal starting point (not tested):

zxing_add_package_stb()

if (BUILD_READERS)
    add_executable (zxing-c-test zxing-c.cpp zxing-c-test.c)
    target_link_libraries (zxing-c-test ZXing::ZXing stb::stb)
endif()

EDIT: you also need to add the line add_subdirectory (wrappers/c) at the end of the top-level CMakeLists.txt.

BTW is it worth adding NULL checks to input arguments?

No.

This would then also work for png images.

Yeah, I know STBI works for PNGs &c, I was just trying different options and that's what I committed lol

you also need to add the line add_subdirectory (wrappers/c) at the end of the top-level CMakeLists.txt.

Added also a BUILD_C_WRAPPER option. (And I'm not really sure how to try the CMakeLists.txt, I'm generally content with Makefiles ^^)

I'll be adding shortly the means to extract the data out of a result but I have a question on "style". The two alternatives I see are:

const char* zxing_Result_data(const zxing_Result* result, int* len);

// OR

const zxing_ByteArray* zxing_Result_bytes(const zxing_Result* result);

const char* zxing_ByteArray_data(const zxing_ByteArray* bytes);
int zxing_ByteArray_size(const zxing_ByteArray* bytes);

The first approach seems more familiar to me, more C-like: the caller gets a pointer to the internal data array, but ownership is not moved. Users must be careful not to use the pointer after calling zxing_Result_delete, or vice-versa, not to call zxing_Result_delete before they no longer need the pointer.

The second approach, to get a pointer we need to copy the whole bytes (new zxing_ByteArray(std::copy(zxing_Result_bytes(result))) IIUC), which is a waste. The ByteArray and the Result may be freed independently, but it doesn't look like a much better situation... Additionally, it's a bit more code to write comparing with the first approach.

If we were only concerned with the bytes() member, then I'd prefer not to copy the data. But there are other properties, especially text() which is certainly the most useful 'result' and there, this approach does not work out of the box because the std::string returned from text() is stored on the stack inside the c-getter and needs to be copied someplace. We could still attach the memory to the zxing_Result struct but it would need to be a different one than ZXing::Result. It would need to store the latter and additionally any of the std::string members once they are accessed via the c-api.

I believe it would be unwise to mix the ownership of the memory semantics for the different getters. So if we go for ownership transfer for the text() member then we should also memcpy the bytes() content to keep it consistent.

In general, I would think the API is cleaner if do not transfer the memory ownership. On the other hand: what is a c-api client going to do with the char *? If it wants to keep it around and not merely printf and forget about it, it would then likely make another copy of it, just to be able to get rid of the zxing_Result *. Then we have just another copy and did not gain anything.

I guess it would be a bit more generic and 'standard' if the returned char * memory is then owned by the client and needs to be freed.

Did I put you off somehow, did I miss an open question your are waiting for the answer or are you simply on vacation? :)

Nah, don't worry, I won't run away :) I just have a ton of things atm and this isn't a priority right now.

@axxel Sorry I left this hanging all of a sudden. I'm hoping I'll be able to relax a bit around mid-June and have time to work on this again.

Hey @axxel, I restarted work on this just now, hoping it would be trivial to add support for the bytes() field. The code in this latest commit compiles alright, but the test program is now complaining the result is invalid (it would say valid before). I'm not sure what happened, but will need some time to figure out what's wrong.

In the meantime, could you help with adding the right CMake files to the right places? And then explain how to use them to build the example program? :D

I don't see how your latest commit can have any effect on your test program. I'm pretty sure it is something else.

I went ahead and added a few more properties of DecodeHints and Result. Also added a ctest case. The test program actually outputs some content now. What else would be required for your original use case?

Hey, thanks for your work! Sorry I was unavailable once again these few days, I'm going slightly insane with some unexpected events lately...

For our use case at work we only need zxing_ReadBarcode and zxing_Result_bytes/zxing_Result_text, so this wrapper is already feature-complete for us (and looking much better than my original hack).

As it is, is it ready to be merged or is there anything missing for you?

I just added zxing_Results_* support which I thought was still a major lack of functionality. Please note that I decided to model "not found" by returning a NULL for both single and multi-symbol variants.

I'll be happy to merge it as is and add missing stuff from there when someone speaks up. I intent to eventually simply add the zxing-c.* to the core library to be automatically available for all libZXing users. But before I do that, it would be nice to get some feedback about the usability of the API.

note that I decided to model "not found" by returning a NULL for both single and multi-symbol variants

Yup, seems to be the most natural.

I'll be happy to merge it as is and add missing stuff from there when someone speaks up. I intent to eventually simply add the zxing-c.* to the core library to be automatically available for all libZXing users. But before I do that, it would be nice to get some feedback about the usability of the API.

Makes sense to me. I won't be able to provide any opinion on advanced use-cases, but once I convert our program to use the new C API, I'll report any issues I find.