From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 5572B1F9FD for ; Sun, 7 Mar 2021 23:23:36 +0000 (UTC) Received: from localhost ([::1]:36334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJ2kJ-0000Jj-5N for normalperson@yhbt.net; Sun, 07 Mar 2021 18:23:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52662) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJ2jr-0000J5-F0 for bug-gnulib@gnu.org; Sun, 07 Mar 2021 18:23:09 -0500 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:34551) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJ2jn-0005N2-5P for bug-gnulib@gnu.org; Sun, 07 Mar 2021 18:23:07 -0500 Received: by mail-ot1-x32e.google.com with SMTP id n23so1882549otq.1 for ; Sun, 07 Mar 2021 15:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=M0oJVK/bRmkRUN/D+kLe6X+03T3KgfphEAsQhdwsMRg=; b=cFrHho6hiNtfXbjUatbJlEAcv9MNARKpOwuK7CxJlCTXGLKLoQyBcto7biQ4dsVMHf UQc7E4CCErRBUWGZvC9Sq1GMQ95jA6D00LuBaGMZ0vNzfHywKcq6zs15BuPeliVjp+jF p4yo4EUlhUmBRlC1nmyhdhsjdYR1EGdKPPMw8= 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; bh=M0oJVK/bRmkRUN/D+kLe6X+03T3KgfphEAsQhdwsMRg=; b=DGAB5l8ALQ+Ay1ImJ3NhucJ7tn/V9sZjGJgP8K3zE3i7JMznffArDeY88saL8CVsYG hKxFZAOutZEmtLA1EiAeD/f7/PXhepgM4XFpTGXHpV8PtWN+fsacVmaWFCLQttsFDb+1 q5rRcvedrQMKtaDplxU93cP/u6cfFrDO0ABeS55b7B/XPsjhAMpCESVbdpOG3balcY4U WMtjKsjvgyCEDR+elNmAJ6WvRVtPlh3PdJpblb9nKK7lbSW61HHH5s7dsiEaDsP/Gp+h w+xGMWDpaTxab8UJNKqGmrCRR/6rX2M1mzv8RTReh5hkUDi9lt0h0OBwF3O85Tslv4RE U+rQ== X-Gm-Message-State: AOAM53346mcKOooaEKvhSIbJQSzYtEZ/3k588veY/f/S7D64x+6Mq2r/ X/2pX2ROmfR7cxB7Fc66O3nCrcKqOCIEOzcPxRI4VZ/y9dhuXw== X-Google-Smtp-Source: ABdhPJzXzb6kWeei3BuY1y/qIb57UYLBNXjbSMGGbEDK2DTJely++s6fuKHa1Su2+vM5UJ0UEyOTOQ2ElRJY/kOhp1U= X-Received: by 2002:a05:6830:903:: with SMTP id v3mr17292683ott.46.1615159381096; Sun, 07 Mar 2021 15:23:01 -0800 (PST) MIME-Version: 1.0 From: Reuben Thomas Date: Sun, 7 Mar 2021 23:22:49 +0000 Message-ID: Subject: NAME_MAX on MingW To: bug-gnulib Content-Type: multipart/alternative; boundary="0000000000002a8cbf05bcfa99c7" Received-SPF: pass client-ip=2607:f8b0:4864:20::32e; envelope-from=rrt@sc3d.org; helo=mail-ot1-x32e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" --0000000000002a8cbf05bcfa99c7 Content-Type: text/plain; charset="UTF-8" NAME_MAX is defined in limits.h. And indeed it is there on Mingw, but guarded by the Windows-specific non-standard macro _POSIX_. I found this suggestion that Windows system headers have not used _POSIX_ since MSVC 2013: https://sourceforge.net/p/mingw-w64/mailman/message/33014416/ However, the macro is still used in the fixed system header with GCC 10 in my bang-up-to-date Mingw installation. I can't see this macro referenced anywhere in gnulib's history. So my question is: is there something gnulib can/should do here? -- https://rrt.sc3d.org --0000000000002a8cbf05bcfa99c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
NAME_MAX is defined in limits.h.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
And indeed it is there on Mi= ngw, but guarded by the Windows-specific non-standard macro _POSIX_.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
I found this suggestion that= Windows system headers have not used _POSIX_ since MSVC 2013: https://sourc= eforge.net/p/mingw-w64/mailman/message/33014416/

However, the macro is still used in the fixed sys= tem header with GCC 10 in my bang-up-to-date Mingw installation.

I can't see this macro refer= enced anywhere in gnulib's history.

<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small" class= =3D"gmail_default">So my question is: is there something gnulib can/should = do here?

--
--0000000000002a8cbf05bcfa99c7--