[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MAX_PATH (or PATH_MAX) assumed to be ~255

From: Ron Norman
Subject: Re: MAX_PATH (or PATH_MAX) assumed to be ~255
Date: Wed, 15 Jul 2020 15:52:34 -0400

My mistake... I had run a check on MAX_PATH which is something my own software has defined locally.

PATH_MAX is defined in the operating system headers as follows:
Centos 8 has 4096
Centos 6 has 4096
RedHat 5 has 4096

SunOS has 1024
HPUX 11.11 PA-RISC has 1023
HPUX 11.23 Itanium has 1023
AIX 7.1 powerpc has 1023

On Wed, Jul 15, 2020 at 2:41 PM James K. Lowden <jklowden@schemamania.org> wrote:
On Wed, 15 Jul 2020 12:02:09 -0400
Jeffrey Walton <noloader@gmail.com> wrote:

Thanks for the report. 

> I'm guessing "destination of size 255" comes from MAX_PATH or
> PATH_MAX. That likely will not hold on Solaris or OS X. I believe
> MAX_PATH is 4096 those OSes.

A reasonable guess, but no.  In call.c we find

#define CALL_BUFF_SIZE          256U
#define CALL_BUFF_MAX           (CALL_BUFF_SIZE - 1U)

I would be interested to know if anyone is using GnuCOBOL on a system
on which PATH_MAX is less than 4096.  I haven't seen one in a long

I don't find any of these reported warnings to be troubling. 

The whole purpose of snprintf and strncpy is to ensure the destination
isn't overflowed.  The premise that a warning is justified if the source
buffer is longer than the target buffer seems pretty weak to me. 

In the case of the warning messages, the potential is that the error
message might -- in the case of a very long entry point name or path --
be chopped off.  In the case of the intrinsic functions, the source
string has already been validated, and no valid string will be too


Ron Norman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]