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=-3.9 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_MED,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 CC60B1F9FD for ; Mon, 8 Mar 2021 09:24:40 +0000 (UTC) Received: from localhost ([::1]:33438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJC7z-0004im-Ip for normalperson@yhbt.net; Mon, 08 Mar 2021 04:24:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJC7n-0004ie-IE for bug-gnulib@gnu.org; Mon, 08 Mar 2021 04:24:27 -0500 Received: from mail-oi1-x230.google.com ([2607:f8b0:4864:20::230]:46645) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJC7e-0001EH-Qy for bug-gnulib@gnu.org; Mon, 08 Mar 2021 04:24:27 -0500 Received: by mail-oi1-x230.google.com with SMTP id f3so10254265oiw.13 for ; Mon, 08 Mar 2021 01:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ygeDvX1J8XhKz+fbpfb3yW0NGtyL3StNWTjf0vRv0no=; b=AH/A3pR7R+9YmycuQiQaRmX/lxTWqTLGa/Z6YAZtT1byqoygCQMlAQptB08lGDGCDV jWM3lia5BmTYAVrfR88Ov+xWysVUi2ktDJl/zAKRhOOv6PuYbDuFpZ09bzUBQFzve1sF /apOgBabU0ZgRfzO1imcZsPov09jUY/bH3RWM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ygeDvX1J8XhKz+fbpfb3yW0NGtyL3StNWTjf0vRv0no=; b=WcKj+BXH8tF9VQOY5mcZdvYUwAT71xTgGvBimBtcDg/nZEJEa4KfXsl8cGZ5koPU98 4lexgM1+Ne6qKd5V91prB14yQXU9VCgRUB8IxjwWG3eISgAXZZ++XskW6dVsz2LnODPe B/EJRplsk4RSNmHRha7+cx95eVg8+sZnErhE2IKJOxzvc3TDxUUXVcWqR7WD791dAE4S D/uUaKBptpENVcqnwQr5MkGRoD0y6eGU0VtfTZVQjpug7W5mWUUzIL77UZRbFoDGmB2j 7oFIoLOMuGRhOqwlLCI73bD38K3YQazicVwJOg6nQ4vJZic/c1KiHamTr9G22J2HQvT0 +dvg== X-Gm-Message-State: AOAM532Ur6/5b6vAq8MKUvgSKjZFUshH2PTurykY4rmDa9O+sQJEXT5d ea+Qsy85N6qm4/640CKvIKOi4pcsE4/87nzQ0W2mWw== X-Google-Smtp-Source: ABdhPJzGEH3x65a4F85AzRbB+xT5kF7zv4lxIpFkyKiUORZX5n7NzQxXy/O1TwVumpSt742hdZDm7hsWXeREmDsmXBA= X-Received: by 2002:aca:1e15:: with SMTP id m21mr15629854oic.62.1615195456532; Mon, 08 Mar 2021 01:24:16 -0800 (PST) MIME-Version: 1.0 References: <1841389.BC9EOF7Wat@omega> In-Reply-To: From: Reuben Thomas Date: Mon, 8 Mar 2021 09:24:05 +0000 Message-ID: Subject: Re: NAME_MAX on MingW To: Bruno Haible Cc: bug-gnulib Content-Type: multipart/alternative; boundary="0000000000006e05b805bd02ffe8" Received-SPF: pass client-ip=2607:f8b0:4864:20::230; envelope-from=rrt@sc3d.org; helo=mail-oi1-x230.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" --0000000000006e05b805bd02ffe8 Content-Type: text/plain; charset="UTF-8" On Mon, 8 Mar 2021 at 00:16, Reuben Thomas wrote: > On Mon, 8 Mar 2021 at 00:14, Bruno Haible wrote: > >> Hi Reuben, >> >> > NAME_MAX is defined in limits.h. >> >> No. POSIX [1] specifies that it may be omitted from , and >> that pathconf (_PC_NAME_MAX) is the right way to access the maximum >> length of a file name component. [2] >> > > Ah, thanks for setting me straight! > Unfortunately, this doesn't help, because pathconf is not present on mingw. So the best I can do is #define _POSIX_ to get the value of NAME_MAX that it has. So given that the pathconf constants are available like this on mingw, perhaps there is something gnulib can do? I'm not sure what is best, whether simply to allow those constants to be found by defining _POSIX_, or to implement pathconf with them. In any case: the information does already exist in some form, and there's no way to get at it portably with gnulib, that I can see. -- https://rrt.sc3d.org --0000000000006e05b805bd02ffe8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 8 Mar 2021 at 00:16, Reuben Thomas <rrt@sc3d.org> wrote:
On Mon, 8 Mar 2021= at 00:14, Bruno Haible <bruno@clisp.org> wrote:
Hi Reuben,

> NAME_MAX is defined in limits.h.

No. POSIX [1] specifies that it may be omitted from <limits.h>, and that pathconf (_PC_NAME_MAX) is the right way to access the maximum
length of a file name component. [2]

Ah, tha= nks for setting me straight!

Unfortunately,= this doesn't help, because pathconf is not present on mingw. So the be= st I can do is #define _POSIX_ to get the value of NAME_MAX that it has.

So given that the pathco= nf constants are available like this on mingw, perhaps there is something g= nulib can do? I'm not sure what is best, whether simply to allow those = constants to be found by defining _POSIX_, or to implement pathconf with th= em.

In any case: the = information does already exist in some form, and there's no way to get = at it portably with gnulib, that I can see.

-= -
--0000000000006e05b805bd02ffe8--