bug-apl
[Top][All Lists]
Advanced

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

Re: [Bug-apl] Quad_SVx.cc some border line condition.


From: Juergen Sauermann
Subject: Re: [Bug-apl] Quad_SVx.cc some border line condition.
Date: Fri, 25 May 2018 15:23:50 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

Hi Hans-Peter,

these changes were introduced recently and only to suppress newly
introduced warnings in gcc 8.1.

So, yes, line 3 does nothing, but in order to suppress the warnings one has
to use the return value of snprintf somehow. The way I read
https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#Warning-Options
seems to suggest that somehow means to set the terminating 0 of the snprintf() result
buffer with the return value of snprintf().

The background of APL_PATH_MAX = 4096 is that unfortunately various #include
files under /usr/include  (even on the same platform) define PATH_MAX differently,
ranging from 128 to 4096. Therefore, even though the theoretical path length can
become > 4096 the underlying file system will not be able to deal with it and then
it makes no difference if a file system call fails due the path being truncated or too long.

Best Regards,
/// Jürgen


On 05/25/2018 12:00 PM, Hans-Peter Sorge wrote:
Hello Juergen,

in Quad_SVx.cc around line 570:

                char filename[APL_PATH_MAX + 1];
                int slen = snprintf(filename, APL_PATH_MAX, "%s/%s",
dirname, entry->d_name);
                if (slen >= APL_PATH_MAX)   filename[APL_PATH_MAX] = 0;

filename will be returned at most APL_PATH_MAX chars long including
\0-termination.
So line -3- will do nothing as filename[APL_PATH_MAX-1] is already '\0'

dirname is defined as  char dirname[APL_PATH_MAX + 1]; 
Just as a sidestep: If dirname was set to APL_PATH_MAX characters +
final \0, then 
the resulting filename will be filled with a truncated path (one char
less ),
the following '/' and d_name are being discarded, resulting in an
invalid filename .      

Here is my take:

dirname is 4096+1 chars long
entry->d_name is 256 chars long
So the max length of filename could then be APL_PATH_MAX(%s)+ 1 (/)  +
255 (%s) +1 (\0).  -> 4353 bytes long.
snprintf strips the trailing \0s from the input and adds one.

               //  PATH + / + NAME + \0
                enum { FN_MAX_LENGTH=APL_PATH_MAX +1 +255 +1};
               char filename[FN_MAX_LENGTH ];                   
               snprintf(filename,FN_MAX_LENGTH , "%s/%s", dirname,
entry->d_name);

Again, I did not dig deeper into the code/spec to find out whether the
maximum filename length
should be 4096+1 bytes, then dirname has to be 4k-256byte long ,
or whether the maximum filename length should be 4353 bytes.

Best regards
Hans-Peter



Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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