delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:from:to:subject:date:message-id:references | |
:in-reply-to:content-type:content-transfer-encoding | |
:mime-version; q=dns; s=default; b=EM6zzIBGVgw/4vE2/sMXCLpeedg+v | |
fWaeh0EoLsZoV5m2Sy1lo16xSpML3qimQVDaFGQe0C9sJgVbrvxuiE/vZjw5lqnK | |
4STqmxYqnelSxgwNV3XGl5BYu1XiZtZlQ3FJ6Aaq4G3wheddqTu5y6J3BWWuMj/D | |
Ww/jlQJdRV/bbI= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:from:to:subject:date:message-id:references | |
:in-reply-to:content-type:content-transfer-encoding | |
:mime-version; s=default; bh=E5+7rPx1t/h7QHWgr04hPUHDu3w=; b=Cep | |
NiRDtTv+fK8Ueri93Md44tUXTvXi/SBQgWlQrFnXUFEXxVELs6+/ailhH79lSZRv | |
OcUihKsLr8havKXecbz7mcp0sLW/4XFepqF79gAFyoNmIraAuHOSVU0lav5dF2Mk | |
jq4rjtKeRDdvmCfjIPXo85v+CHEj6yx9s4bpqfhw= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
Authentication-Results: | sourceware.org; auth=none |
X-Spam-SWARE-Status: | No, score=-2.1 required=5.0 tests=AWL,MIME_BASE64_BLANKS autolearn=ham version=3.3.2 |
X-HELO: | gecko.sbs.de |
From: | "Schwarz, Konrad" <konrad DOT schwarz AT siemens DOT com> |
To: | Eric Blake <eblake AT redhat DOT com>, |
The Cygwin Mailing List <cygwin AT cygwin DOT com>, | |
"newlib AT sourceware DOT org" <newlib AT sourceware DOT org> | |
Subject: | RE: allowing redefinition of setjmp()? |
Date: | Mon, 26 Jan 2015 10:19:28 +0000 |
Message-ID: | <A45B1767F1002449A37508C2CC6003D707556F@DEFTHW99EJ1MSX.ww902.siemens.net> |
References: | <54C2C68E DOT 5090100 AT redhat DOT com> |
In-Reply-To: | <54C2C68E.5090100@redhat.com> |
MIME-Version: | 1.0 |
X-MIME-Autoconverted: | from base64 to 8bit by delorie.com id t0QAKK1H030540 |
> -----Original Message----- > To: The Cygwin Mailing List; newlib AT sourceware DOT org > Subject: allowing redefinition of setjmp()? > Reading POSIX, I see that Cygwin is compliant, and readline is at > fault. > http://pubs.opengroup.org/onlinepubs/9699919799/functions/setjmp.html > is clear: > > "It is unspecified whether setjmp() is a macro or a function. If a > macro definition is suppressed in order to access an actual function, > or a program defines an external identifier with the name setjmp, the > behavior is undefined." Honestly, this is what I expected. > But as the redefine works in Linux, I'm wondering if we tweak things in > Cygwin and/or newlib to allow it to work here too. Maybe by making an > entry point __setjmp() as an alias for setjmp(), and defining > sigsetjmp() in terms of __setjmp(), so that when someone adds a #define > wrapper for setjmp, it is no longer a mutually recursive macro naming > scenario. It this really worth it? > In the meantime, I'm resorting to patching up readline code to quit > trying to (re)define setjmp. Stating the obvious, all you need to do is globally replace setjmp() with e.g. readline_setjmp().
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |