On Sun, May 28, 2023 at 08:00:37AM +0200, tlaro...@polynum.com wrote:
> Le Sat, May 27, 2023 at 08:50:21PM +, David Holland a ?crit :
> > On Sat, May 27, 2023 at 09:10:34AM +0200, tlaro...@polynum.com wrote:
> > > Shouldn't be MAXPATHLEN be defined as PATH_MAX - 1?
> >
> > No. They're th
Le Sat, May 27, 2023 at 08:50:21PM +, David Holland a écrit :
> On Sat, May 27, 2023 at 09:10:34AM +0200, tlaro...@polynum.com wrote:
> > Shouldn't be MAXPATHLEN be defined as PATH_MAX - 1?
>
> No. They're the same. The existence of some old code where somebody
> didn't read the definition ca
Date:Sat, 27 May 2023 20:15:01 +0200
From:"J. Hannken-Illjes"
Message-ID: <4365151a-b7d5-437a-a6a4-d586d5bf6...@mailbox.org>
| The magic needed here is "blanket" from RUMPHIJACK(3) ...
Thanks. That's something I would never have gotten to.
| The attached diff
On Sat, May 27, 2023 at 09:10:34AM +0200, tlaro...@polynum.com wrote:
> Shouldn't be MAXPATHLEN be defined as PATH_MAX - 1?
No. They're the same. The existence of some old code where somebody
didn't read the definition carefully (or that predates a clear
definition) doesn't change that. Not sure
> Today I am wondering why we need to [...] canonicalise the block
> device name for mount.
> Currently I am seeing 4 reasonable choices...
> 1) just omit the pathadj() of the block device name, and just use
> whatever the user says to use, unchanged. I doubt anything would
> really be affected
Le Sat, May 27, 2023 at 11:56:16PM +0700, Robert Elz a écrit :
> I'm dual-posting this to tech-kern and tech-userlevel, as while it is
> a userlevel issue, it could have kernel implications. Please respect
> the Reply-To and send replies only to tech-userlevel
>
> You may have noticed that a rec
>> Today I am wondering why we need to [...] canonicalise the block
>> device name for mount.
> Isn't it because in order to be able to compare strings, the path has
> to have an uniq (canonical) form, independent from the way the user
> enters it? For example, at the user level, how mount(8) coul
Le Sat, May 27, 2023 at 11:56:16PM +0700, Robert Elz a écrit :
> I'm dual-posting this to tech-kern and tech-userlevel, as while it is
> a userlevel issue, it could have kernel implications. Please respect
> the Reply-To and send replies only to tech-userlevel
>
> You may have noticed that a rec
In /usr/src/usr.sbin/inetd/parse.c, a linked list of file_list
structures is included.
When adding a config include file, realpath(3) is called:
parse.c:include_configs()
1193
new_file.abs = realpath(CONFIG, NULL);
new_file.abs is not tested against NULL, and the structure is
inconditio
In src/sys/sys/param.h, MAXPATHLEN is defined as PATH_MAX.
In POSIX, PATH_MAX is defined like this:
{PATH_MAX}
Maximum number of bytes the implementation will store as a pathname
in a user-supplied buffer of unspecified size, including the terminating
null character. Minimum number the implem
10 matches
Mail list logo
