Axel Waggershauser

xcode complains about -Wshorten-64-to-32 (mostly)

Hi Martin, please close this issue.

Addendum: there is a copy'n'paste error, the conforming content must include the checksum char 8 at the end.

GS1 DataBar inconsistencies

Re ZBarcode_EncodeCPP: I don't think that is worth it. At least not for zxing-cpp. There is currently just one line with a cast (ZBarcode_Encode_and_Buffer(zint, (uint8_t*)data, size, 0)) that would benefit from this. I also don't quite understand why you want to make a distinction between C and C++ in this regard. Having source and text being of type const char* seems to benefit both C and C++ in terms of usability. And where would those warnings for C users come from? Are you talking about the...

Status is still open, although the issue is fixed. I don't see how I can close the issue. Can this only be done by admins?

I got the impression, that our discussion last year concluded in 1. text would be better modeled as char* 2. text, encoded_data, errtxt and row_height could (/should in IMHO) be dynamically allocated according to the size required. Is that still on the table? Would you consider doing that before releasing 2.14.0? Also related would be the subject of adding the option to libzint to output the encoded bits. See here.

Compile issue in output.c when included in external build