> Thanks for pointing this out. As discussed with deraadt@ it's probably
> not a good idea to mimic too closely the algorithm in the kernel.
If the accounting in find is byte-for-byte accurate, it will be fragile.
It may be better if find consistantly undershoots when estimating.
On Thu, Apr 09 2020, Marc Espie wrote:
> On Thu, Apr 09, 2020 at 02:44:14PM +0200, Jeremie Courreges-Anglas wrote:
>> On Thu, Apr 09 2020, Jeremie Courreges-Anglas wrote:
>> > find(1) uses ARG_MAX to compute the maximum space it can pass to
>> > execve(2). This doesn't fly if userland and the ke
On Thu, Apr 09, 2020 at 02:44:14PM +0200, Jeremie Courreges-Anglas wrote:
> On Thu, Apr 09 2020, Jeremie Courreges-Anglas wrote:
> > find(1) uses ARG_MAX to compute the maximum space it can pass to
> > execve(2). This doesn't fly if userland and the kernel don't agree, as
> > noticed by some afte
On Thu, 09 Apr 2020 14:44:14 +0200, Jeremie Courreges-Anglas wrote:
> Right now we don't account for the space used by the environment.
> We get lucky either because of the 5000 max args limit or because
> environment size usually fits in the 4096 bytes safety net.
>
> The diff below uses the same
On Thu, Apr 09 2020, Jeremie Courreges-Anglas wrote:
> find(1) uses ARG_MAX to compute the maximum space it can pass to
> execve(2). This doesn't fly if userland and the kernel don't agree, as
> noticed by some after the recent ARG_MAX bump.
>
> --8<--
> ritchie /usr/src/usr.bin/find$ obj/find /u
On Thu, 09 Apr 2020 03:47:45 +0200, Jeremie Courreges-Anglas wrote:
> While having the kernel and userland out of sync is not a good idea,
> making find(1) more robust by using sysconf(3) is easy. This is what
> xargs(1) already does.
OK millert@.
- todd
find(1) uses ARG_MAX to compute the maximum space it can pass to
execve(2). This doesn't fly if userland and the kernel don't agree, as
noticed by some after the recent ARG_MAX bump.
--8<--
ritchie /usr/src/usr.bin/find$ obj/find /usr/src/ -type f -exec true {} +
find: true: Argument list too l
