Path: news.eternal-september.org!eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita Montero <Bonita.Montero@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Sat, 7 Jun 2025 06:24:53 +0200
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <1020eu8$2pifl$1@raubtier-asyl.eternal-september.org>
References: <100h650$23r5l$1@dont-email.me> <101ft3d$1feqh$2@dont-email.me>
 <101gq6l$1rdgj$1@raubtier-asyl.eternal-september.org>
 <101h0an$1tkqk$1@dont-email.me>
 <101jk7i$34erh$1@raubtier-asyl.eternal-september.org>
 <1nj%P.3454$mAv4.2422@fx34.iad>
 <101nc3o$5pjd$1@raubtier-asyl.eternal-september.org>
 <h6H%P.676329$McHf.348392@fx15.iad>
 <101u8sb$25g28$1@raubtier-asyl.eternal-september.org>
 <3FC0Q.931590$G6Lf.397684@fx17.iad>
 <101v7d7$2cudl$1@raubtier-asyl.eternal-september.org>
 <CvF0Q.1165311$McHf.1120306@fx15.iad>
 <101v8ce$2d5it$1@raubtier-asyl.eternal-september.org>
 <0e9619f7d873a4ec436f017bac1192c73c5283e5.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 07 Jun 2025 06:24:40 +0200 (CEST)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="8d765f89af69f03be944f05a81e936fc";
	logging-data="2935285"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18EzeXgTL+x9s1SgJbfp5NfM+3M4cwwKa8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:x34TJ6cJvpk1PiZLfCUuFxp+soU=
In-Reply-To: <0e9619f7d873a4ec436f017bac1192c73c5283e5.camel@gmail.com>
Content-Language: de-DE

Am 06.06.2025 um 22:04 schrieb wij:
> On Fri, 2025-06-06 at 19:26 +0200, Bonita Montero wrote:
>> Am 06.06.2025 um 19:24 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>> Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
>>>>>
>>>>>>>>>         The fchownat() function shall be equivalent to the chown() and lchown()
>>>>>>>>>         functions except in the case where path specifies a relative path. In
>>>>>>>>>         this case the file to be changed is determined relative to the directory
>>>>>>>>>         associated with the file descriptor fd instead of the current working
>>>>>>>>>         directory. If the access mode of the open file description associated
>>>>>>>>>         with the file descriptor is not O_SEARCH, the function shall check
>>>>>>>>>         whether directory searches are permitted using the current permissions
>>>>>>>>>         of the directory underlying the file descriptor. If the access mode is
>>>>>>>>>         O_SEARCH, the function shall not perform the check.
>>>>>>>>
>>>>>>>> And why is this relevant for directory_iterator or
>>>>>>>> recursive_directory_iterator ?
>>>>>>>
>>>>>>> Why are you asking this question on comp.lang.c?
>>>>>>
>>>>>> Because you can have it easier than with opendir() / readdir().
>>>>>
>>>>> Personally, I'd use nftw to iterate over a path.
>>>>>
>>>>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html
>>>>
>>>> That would be much nicer with a lambda which can take the context
>>>> of the calling function.
>>>>
>>>
>>> That's a matter of opinion.
>>
>> It results in much less code.
> 
> That is illusion, particularly in this case (about directory).

I've shown the code. In C++17 iterating through a single directory and
printing it is two lines of code.

> Most serious programs will 'invent' their own functions, even their own
> 'sugar syntax'...

Not to iterate through a directory in C++.

> 'sugar syntax'... result would be better than 'directory_iterator'.

Why ?

> In general, no need for such things as 'directory_iterator' in C-library.


In C you're forced to write ten times the code if you include error
handling.

>> Just like a lambda passed
>> to std::sort() which takes context of the calling function.
>>
>>> In any case, nftw is a C function and C doesn't support lamda functions.
>>
>> Lambdas without capture can be converted to C function-pointers.
>