From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id A4A1F3858C52 for ; Mon, 12 Feb 2024 17:11:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A4A1F3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A4A1F3858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.132.182.106 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707757920; cv=none; b=g6N1a0DzlIIWji/y6nAxJO7yRNq+PZ+gy/Qeen1T6sO47Nzwo8VqUdgI/+47yNZ99Rwi47fXIw1wiZ3ShLPDBRufBEFOgP19MY7hnOptJrPRERgQETHBMJ+BmmARGcE+VT2uUHAlsQuYq/mfN+i+U0E7CVM/kPdVxzSbfhNs2g0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707757920; c=relaxed/simple; bh=XQQJlMjIAgt33yc13Esc0XbrROz05UL75qQVF5QO8sA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=T5Foo0h7ljWISDwJPNo+fmdxFLL1D/k0abuQXprCmcXvG/aO0XupjlBuDz04hd2qjhmaF97TrOMQQfTgGXwgQF3Crx86cavvSxgHuBupckwRrcbBT6dGg+ieVxZ0ycooMQvTdODANbMXzdzoSFSeG1FD+h7FP35Vd1dYci1YTuI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0241204.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 41CFcK3s026055; Mon, 12 Feb 2024 18:11:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s= selector1; bh=0/14VBO8BMj1umJGECDdw3hnyhp3bnuo8q6P8TrOfhI=; b=Me I6kFwv1jyKJufggi0dM2f99MHgANibaZUVaznOPYaR7xOqH5ucK3oUT5WMTSDZ+Z GP8HmNHxMsihAkGbcFsZYCDYPjWa+TmCyq1w5AcNvKaf1l7RzQaTxh7Inc6E6q2P KtuKHOdi4nqFBEaSjgLICltgyJgFWiCd/NsAWH3wTQYg+CJrUefrXqijYs0EWJXo uD05xuYrHRJkdL7TTsQvPyVSkIZlZyTpHY98DUFAWy2QpR9BUacZHR8sC08GoOmq ZmicwAmh9eldcfmngusfyjnyjuztJLBTI5BIFZfZnahXgrkmbSIoSYhv2mJSe24H K3UO8x84SH2MfIRV4kVA== Received: from beta.dmz-ap.st.com (beta.dmz-ap.st.com [138.198.100.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3w62h0qgms-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Feb 2024 18:11:56 +0100 (CET) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-ap.st.com (STMicroelectronics) with ESMTP id 9197D4002D; Mon, 12 Feb 2024 18:11:53 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 6270826B334; Mon, 12 Feb 2024 18:11:44 +0100 (CET) Received: from [10.252.4.95] (10.252.4.95) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 12 Feb 2024 18:11:43 +0100 Message-ID: Date: Mon, 12 Feb 2024 18:11:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Mismatch between newlib and glibc regarding fileno Content-Language: en-US To: Andrew Pinski , Newlib , Yvan Roux References: <52858367-f116-413e-b107-61c8afce156b@foss.st.com> <42f199ba-8905-4846-9768-54342244610e@foss.st.com> From: Torbjorn SVENSSON In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.4.95] X-ClientProxiedBy: SHFCAS1NODE1.st.com (10.75.129.72) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-12_14,2024-02-12_03,2023-05-22_02 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-02-12 17:40, Corinna Vinschen wrote: > On Feb 12 17:33, Corinna Vinschen wrote: >> On Feb 12 16:36, Torbjorn SVENSSON wrote: >>> Okay, so newlib is more restrictive than glibc on this topic. >>> I will prepare a patch for test cases in GCC with defining _POSIX_SOURCE so >>> that the test cases succeed for newlib. >> >> It looks like it. But I do wonder if that's really intended by glibc. >> I ran a quick test, first under newlibL >> >> $ g++ -std=c++98 -E -dM /usr/include/features.h | grep VISIBLE >> #define __LARGEFILE_VISIBLE 0 >> #define __ISO_C_VISIBLE 1999 >> #define __XSI_VISIBLE 0 >> #define __GNU_VISIBLE 0 >> #define __BSD_VISIBLE 0 >> #define __POSIX_VISIBLE 0 >> #define __SVID_VISIBLE 0 >> #define __ATFILE_VISIBLE 0 >> #define __MISC_VISIBLE 0 >> >> then under glibc: >> >> $ g++ -std=c++98 -E -dM x.cc | grep '#define __USE' >> #define __USE_UNIX98 1 >> #define __USE_FORTIFY_LEVEL 0 >> #define __USE_ISOC11 1 >> #define __USE_ISOC95 1 >> #define __USE_ISOC99 1 >> #define __USE_XOPEN 1 >> #define __USE_XOPEN2K 1 >> #define __USE_POSIX199506 1 >> #define __USE_GNU 1 >> #define __USE_XOPEN2KXSI 1 >> #define __USE_XOPEN2K8 1 >> #define __USE_POSIX 1 >> #define __USER_LABEL_PREFIX__ >> #define __USE_MISC 1 >> #define __USE_POSIX2 1 >> #define __USE_LARGEFILE64 1 >> #define __USE_POSIX199309 1 >> #define __USE_XOPEN2K8XSI 1 >> #define __USE_LARGEFILE 1 >> #define __USE_XOPEN_EXTENDED 1 >> #define __USE_DYNAMIC_STACK_SIZE 1 >> #define __USE_ATFILE 1 >> >> How is it possible that with -std=c++98, everything and the kitchen sink >> is enabled? Is that really correct?!? > > ...especially since __STRICT_ANSI__ is defined to 1 in this scenario. Do you know any way to identify if this is the intended behavior or if it's an overlook in the glibc end? Regardless if glibc is doing this deliberately or not, I suppose the correct thing is to manually define _POSIX_VISIBLE in the test case, right?