|
From: | Ron Norman |
Subject: | Re: MAX_PATH (or PATH_MAX) assumed to be ~255 |
Date: | Wed, 15 Jul 2020 15:58:43 -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 4096Centos 6 has 4096RedHat 5 has 4096SunOS has 1024HPUX 11.11 PA-RISC has 1023HPUX 11.23 Itanium has 1023AIX 7.1 powerpc has 1023On 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 COB_MAX_COBCALL_PARMS 16
#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
time.
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
long.
--jkl
--CheersRon Norman
[Prev in Thread] | Current Thread | [Next in Thread] |