From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 01E5F2438E for ; Wed, 18 Sep 2024 02:29:36 +0200 (CEST) Received: (qmail 11741 invoked by uid 550); 18 Sep 2024 00:29:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11697 invoked from network); 18 Sep 2024 00:29:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=qcppdkim1; bh=5ZCuzwn2KtmdP/ZdJ8Pd+f 9aP13cPt8Altid04PK1+Y=; b=izxhEZjzqRaTKN/0si7ElgvXbbE0qJOLzYUf1m VPPD27oivXOUMw6HAL3LCO/4TURppHZj8suwfOD/3g/mrk0W7GhHjsnZq5r1Ibt8 0cDesFdqnOCQsUrBGflQsf7hRLCnhoakow3yZuP1twQXGVREb8UojzUeuREbJ6v+ mGVEzsuFHpPeRhswtEXVfp0WHowC9ArbrmRiSPVrgcwSmKfLTVW77yAdI8apzeB8 SfCIFR0ENuU0wRBeM+dAZGHo6IQg4s5yXpNTatKqOi5Oco8V2LGY/Z5n9ltE+WfM I/nNYCYq3+nQFdqxgsTZwIMB+zKkpeCEx6hYB6/3T95Yetww== Message-ID: <5179cce6-b63b-4687-8f25-f02a5fd93679@quicinc.com> Date: Tue, 17 Sep 2024 19:29:17 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Brian Cain Content-Language: en-US To: , =?UTF-8?Q?Alex_Benn=C3=A9e?= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: 0r0NRcQe__TskyUohxCKFhE5CqsVa1gA X-Proofpoint-GUID: 0r0NRcQe__TskyUohxCKFhE5CqsVa1gA X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam policy=outbound score=89 phishscore=0 impostorscore=0 clxscore=1011 adultscore=0 mlxscore=89 suspectscore=0 malwarescore=0 priorityscore=1501 spamscore=89 bulkscore=0 lowpriorityscore=0 mlxlogscore=-90 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2408220000 definitions=main-2409180002 Subject: [musl] _GNU_SOURCE and _LARGEFILE_SOURCE In the "WHATSNEW" text, there's an item from 0.9.2 that states "- make _GNU_SOURCE imply _LARGEFILE64_SOURCE".  Is that intended to be the case generally?  I ask because in 25e6fee2 (remove LFS64 programming interfaces (macro-only) from _GNU_SOURCE, 2022-09-27) it stated "portable software should be prepared for them not to exist" and "the intent is that this be a very short-term measure and that the macros be removed entirely in the next release cycle." This comes up because in the QEMU project, there's a linux multiarch test case that uses readdir64 and it does define _GNU_SOURCE but does not define _LARGEFILE64_SOURCE and as such the cross compiler complains that there's no declaration of readdir64 before the call site.  I suppose that the test case would be more portable if it defined _LARGEFILE64_SOURCE.  But I'd also be happy to send a patch to musl that could have _GNU_SOURCE imply _LARGEFILE64_SOURCE (again?) if that's desired.  But - I gather that defining the macros is not what we want.  Instead of macros I should add declarations for readdir64() and its LFS64 friends, but only when _LARGEFILE64_SOURCE is defined? -Brian