Date: Wed, 28 Mar 2018 11:31:39 +0100 From: Jon Scobie <jon.scobie@...lsign.com> To: musl@...ts.openwall.com Cc: Tom Cosgrove <tom.cosgrove@...lsign.com>, Jason Page <jason.page@...lsign.com>, Sam Carroll <sam.carroll@...lsign.com> Subject: Maybe not a bug but a possible omission? Hi. We are currently using musl in the context of Alpine 3.7 in a docker container. The application in question I am writing is in golang (1.9.4) but I have to interface to some in house cryptographic libraries we write in C. To help us achieve this with the minimal of fuss and also to generate bindings to other languages, I am using SWIG 3.0.12. I have come across a couple of issues which do not appear when using glibc and they both centre on stdint.h If I include <stdint.h> as part of the swig interface and it tries to wrap it, it fails on the wrapper compilation of #defines for anything using INT64_MIN, INT64_MAX etc. Initially, I thought this was to do with the swig definitions for 64 bit but on looking at the code and comparing what glibc defines for this, it boiled down to the rvalue definitions for these macros. Basically, glibc wraps these with another macro so where we have the definition in musl as :- #define INT64_MIN (-1-0x7fffffffffffffff) the equivalent glibc definition is the equivalent of #define INT64_MIN (-1-0x7fffffffffffffffL) The issue is that swig has no idea what type INT64_MAX is if you don't specifically state what it is so it treats it as a goint - which is not a long (or long long). Is there any value in changing the musl definitions of these so they are precise in their definition or have I missed something? A slightly different issue (and one which might be more a swig issue than musl, although it works on glibc) is the definitions for WCHAR_MAX and WCHAR_MIN. On glibc, these are defined as whole values and not as 0xffffffffu+L'\0', for example. The wrappers end up messing these up as they escape all the back ticks and this is not correct. As I said, a possible issue in swig based on a side effect which doesn't exist when using glibc with these definitions. Interested in hearing any opinion on this. Regards, Jon Scobie -- ---- The information contained in this communication is private and confidential and may contain privileged material. It is intended solely for use by the recipient(s). Copying, distributing, disclosing or using any of the information in it or any attachments is strictly prohibited and may be unlawful. Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.