From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20735 invoked by alias); 1 Nov 2018 20:42:55 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 20724 invoked by uid 89); 1 Nov 2018 20:42:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*F:D*gov, 5x, 71 X-HELO: nihcesxwayst04.hub.nih.gov Received: from nihcesxwayst04.hub.nih.gov (HELO nihcesxwayst04.hub.nih.gov) (165.112.13.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Nov 2018 20:42:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nih.gov; i=@nih.gov; q=dns/txt; s=NIH; t=1541104971; x=1572640971; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=C3pAo/MQyF+kBZP4XTu0PjJBToniIWGtisH69xz+gLA=; b=QjdNeYirGj1Oodcg0vRbqMZ5DV0uMyszAY1PvCWb6WnOWKdk2P85PGDw NAohzojU10UT7v22DdL47tJCm4ve9sEvQh7WXLQynDvsj/gkVIl8E5xDD NTm3JCe+4JV4/+t3x1dfQ9QNKTNGzc+n/aI6TNNoOlSt3BI2UQ/I38uhi 80rFON/9CK0XOjfNyjUrmOsgY1J2KYqMGVNQdf1tsdoESinVhUGnONdyZ aJmDujTWTK6+kVs9V2FyksKiPrNvp+7JSi6sPAYstR4BQcqatQGZ88E7S 1tFncCXVw44I0lEXVCW2rVu5jENPR5lkDmLiF6gt2Qwbmd5NiIXJbXQyF Q==; Received: from uccbx03.nih.gov (HELO ces.nih.gov) ([156.40.79.153]) by nihcesxwayst04.hub.nih.gov with ESMTP; 01 Nov 2018 16:42:38 -0400 Received: from uccbx04.nih.gov (156.40.79.154) by uccbX03.nih.gov (156.40.79.153) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 1 Nov 2018 16:42:38 -0400 Received: from GCC01-CY1-obe.outbound.protection.outlook.com (156.40.79.132) by uccbx04.nih.gov (156.40.79.154) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 1 Nov 2018 16:42:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nih.onmicrosoft.com; s=selector1-ncbi-nlm-nih-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C3pAo/MQyF+kBZP4XTu0PjJBToniIWGtisH69xz+gLA=; b=OlsXIZqI3U8P2gb6GfhqhWTxS3EtsjXB8SxACZfdkN+D2ecHMGIdgEhpC78QFr9Qx+rzFGko8961EnDeBCOjwaNl17LfZD/f7F4+jgByHl8TeJ99ChXV3hIQDmo2flbxE8Exo2LB5/o0Y/Bl8sLHXV2WpYZVXs3xV4gok/lIMBA= Received: from SN6PR09MB3247.namprd09.prod.outlook.com (20.177.250.225) by SN6PR09MB3248.namprd09.prod.outlook.com (20.177.251.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.27; Thu, 1 Nov 2018 20:42:36 +0000 Received: from SN6PR09MB3247.namprd09.prod.outlook.com ([fe80::4d0a:8286:ea4c:3885]) by SN6PR09MB3247.namprd09.prod.outlook.com ([fe80::4d0a:8286:ea4c:3885%5]) with mapi id 15.20.1250.020; Thu, 1 Nov 2018 20:42:36 +0000 From: "Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin" Reply-To: "Lavrentiev, Anton (NIH/NLM/NCBI) [C]" To: "'cygwin@cygwin.com'" Subject: iostream exceptions uncaught with CYGWIN GCC/7.3.0 Date: Thu, 01 Nov 2018 20:42:00 -0000 Message-ID: authentication-results: spf=none (sender IP is ) smtp.mailfrom=lavr@ncbi.nlm.nih.gov; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Return-Path: lavr@ncbi.nlm.nih.gov X-SW-Source: 2018-11/txt/msg00016.txt.bz2 Hi, Please consider the following code: $ cat bug.cpp=20 #include using namespace std; void fun() { string dummy; cin >> dummy; } int main() { cout << "FAIL =3D 0x" << hex << ios::failbit << endl; cout << "EOF =3D 0x" << hex << ios::eofbit << endl; cout << "BAD =3D 0x" << hex << ios::badbit << endl; cin.exceptions(ios::eofbit | ios::failbit); try { fun(); } catch (ios_base::failure&) { cerr << "Failure caught!" << endl; } catch (...) { cerr << "Failure uncaught! 0x" << hex << cin.rdstate() << endl; } return 0; } When this program is compiled and run on Linux, the exception gets caught: $ uname -a Linux iebdev11 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 20= 18 x86_64 x86_64 x86_64 GNU/Linux $ g++ --version g++ (GCC) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ -Wall bug.cpp -o bug $ ./bug < /dev/null FAIL =3D 0x4 EOF =3D 0x2 BAD =3D 0x1 Failure caught! However, same commands on Cygwin, and the exception goes unhandled: $ uname -a CYGWIN_NT-10.0 NCBIPC9135 2.11.1(0.329/5/3) 2018-09-05 10:24 x86_64 Cygwin $ gcc --version gcc (GCC) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ -Wall -o bug bug.cpp $ ./bug < /dev/null FAIL =3D 0x4 EOF =3D 0x2 BAD =3D 0x1 Failure uncaught! 0x6 We've seen this behavior before on Linux too, when the C++ ABI was changed = (w/GCC 5.x). I guess CYGWIN packages a version of C++ STDLIB whose ABI is = incompatible with default compiler settings. Here's some explanation of what might be the culprit. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html says th= at: > Using the default configuration options for GCC the default value of the = macro is 1 which causes the new ABI to be active, so to use the old ABI you= must explicitly define the macro to 0 before including any library headers. > (Be aware that some GNU/Linux distributions configure GCC 5 differently = so that the default value of the macro is 0 and users must define it to 1 t= o enable the new ABI.) > One exception type does change when using the new ABI, namely std::ios_ba= se::failure. This is necessary because the 2011 standard changed its base c= lass from std::exception to std::system_error, which causes its layout to c= hange. Exceptions due to iostream errors are thrown by a function inside li= bstdc++.so, so whether the thrown exception uses the old std::ios_base::fai= lure type or the new one depends on the ABI that was active when libstdc++.= so was built, not the ABI active in the user code that is using iostreams. = This means that for a given build of GCC the type thrown is fixed. In curre= nt releases the library throws a special type that can be caught by handler= s for either the old or new type, but for GCC 7.1, 7.2 and 7.3 the library = throws the new std::ios_base::failure type, and for GCC 5.x and 6.x the lib= rary throws the old type. Catch handlers of type std::ios_base::failure wil= l only catch the exceptions if using a newer release, or if the handler is = compiled with the same ABI as the type thrown by the library. Handlers for = std::exception will always catch iostreams exceptions, because the old and = new type both inherit from std::exception. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple