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.