From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12642 Path: news.gmane.org!.POSTED!not-for-mail From: Jon Scobie Newsgroups: gmane.linux.lib.musl.general Subject: Maybe not a bug but a possible omission? Date: Wed, 28 Mar 2018 11:31:39 +0100 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113fb884318f950568768339" X-Trace: blaine.gmane.org 1522232993 26769 195.159.176.226 (28 Mar 2018 10:29:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 10:29:53 +0000 (UTC) Cc: Tom Cosgrove , Jason Page , Sam Carroll To: musl@lists.openwall.com Original-X-From: musl-return-12656-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 28 12:29:49 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1f18Ky-0006t6-Ox for gllmg-musl@m.gmane.org; Wed, 28 Mar 2018 12:29:49 +0200 Original-Received: (qmail 9741 invoked by uid 550); 28 Mar 2018 10:31:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9690 invoked from network); 28 Mar 2018 10:31:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callsign.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=CKVCtQ/HIwWwCZo8pEJn5IssjhsIeGc0hOD86UZpxpc=; b=Ggsq1V+3mEhWKL+JsbNaneEBc0IUdQTIrtdp5Y+i9+lzfDc2oquemG0vdh/Twufhwm HALq2FjlB1Rg3M3ky98Fj+TxBr/YF6JuTRvVoB+467IzaPDeTuus/QWDeGDuWp2wbVgT zIjKHEXe4bgkGT+5RBiXkW3jG2tPWngCxu9+o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=CKVCtQ/HIwWwCZo8pEJn5IssjhsIeGc0hOD86UZpxpc=; b=M52VTCQbBCWx0nMR4swkM821XtWsU9EirnbJSPjxY+uxbUcEWACKr/GbTvtmPIkFDu 2SFOrQ8f3Uwacuk6hgLy62rRVLPVjFDsSh2+tG+FZl0KjT2ZUEWpyagYmWezfsPhEclc HZC6qOmcu6lbzItiUkJ/jmlHxJDkYWpwazlViFHB6EERGLTMhsQxgm7Jbr58tmQHT913 0inh82XzL+Xaq+YWBIJOjj0ztrm8JC8dfsxRXFgP8m/3u3I3i6D2BtNIs+dYGEaQZa19 4hewZiP2BkRpWRyLhdqIh7ZiFG7kuYX1An1a4CJnn8bGlseAZMfxeChA83VXEGK2F6AE FA3Q== X-Gm-Message-State: AElRT7FV+NAg5+t8/gTCmsCi6r4K7gXthbRqVK4c4f1vVwpHdKbYy45q 6WcxcA67VpOu+p+7hothDLKUHqee0wWxc7sRhb4A1dhi7lOk9nF2QeEUcWD2RY9BzkLHEAYeA+j cPCu+QaCRaYsSad6jzWSTQKs2rn+szOwg X-Google-Smtp-Source: AIpwx48DGoSVxUyo7WQx18LC3v8w8GWGNH2EQNrNnx394YhPyx4SIBVm+gA3pAp1ZKQ2XFzFGs48RJ8SKO7TXi0X5d4= X-Received: by 10.107.8.36 with SMTP id 36mr6942114ioi.167.1522233100037; Wed, 28 Mar 2018 03:31:40 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:12642 Archived-At: --001a113fb884318f950568768339 Content-Type: text/plain; charset="UTF-8" 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 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. --001a113fb884318f950568768339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi. We are currently using musl in the context of Alp= ine 3.7 in a docker container.=C2=A0
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.=C2=A0
To help us achieve t= his with the minimal of fuss and also to generate bindings to other languag= es, I am using SWIG 3.0.12.

I have come across a c= ouple of issues which do not appear when using glibc and they both centre o= n stdint.h

If I include <stdint.h> as part o= f the swig interface and it tries to wrap it, it fails on the wrapper compi= lation of #defines for anything using INT64_MIN, INT64_MAX etc.=C2=A0
=

Initially, I thought this was to do with the swig defin= itions for 64 bit but on looking at the code and comparing what glibc defin= es 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=C2=A0 = (-1-0x7fffffffffffffff)

the equivalent glibc d= efinition is the equivalent of

#define INT64_MIN= =C2=A0 (-1-0x7fffffffffffffffL)

The issue is t= hat swig has no idea what type INT64_MAX is if you don't specifically s= tate what it is so it treats it as a goint - which is not a long (or long l= ong).

Is there any value in changing the musl defi= nitions of these so they are precise in their definition or have I missed s= omething?


A slightly different issu= e (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=C2=A00xffffffffu+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 pri= vate and confidential and may contain privileged material. It is intended s= olely for use by the recipient(s). Copying, distributing, disclosing or usi= ng any of the information in it or any attachments is strictly prohibited a= nd may be unlawful. --001a113fb884318f950568768339--