Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Sat, 07 Jun 2025 19:58:01 +0800
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <1e3f53801e22a94356b9b0aded0ed7d33e67fd06.camel@gmail.com>
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>
	 <1020eu8$2pifl$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 07 Jun 2025 13:58:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9bd70c4a0c87ec4ace2a3a7ed7005e97";
	logging-data="3138771"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18nQONnpemrdx6cePdCLPnA"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:wXekb21rj3IXe0pshfjaefS6ERw=
In-Reply-To: <1020eu8$2pifl$1@raubtier-asyl.eternal-september.org>

On Sat, 2025-06-07 at 06:24 +0200, Bonita Montero wrote:
> 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:
> > > > > >=20
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The fchownat=
() function shall be equivalent to the chown() and lchown()
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 functions ex=
cept in the case where path specifies a relative path. In
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this case th=
e file to be changed is determined relative to the directory
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated w=
ith the file descriptor fd instead of the current working
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directory. I=
f the access mode of the open file description associated
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with the fil=
e descriptor is not O_SEARCH, the function shall check
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether dire=
ctory searches are permitted using the current permissions
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the direc=
tory underlying the file descriptor. If the access mode is
> > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O_SEARCH, th=
e function shall not perform the check.
> > > > > > > > >=20
> > > > > > > > > And why is this relevant for directory_iterator or
> > > > > > > > > recursive_directory_iterator ?
> > > > > > > >=20
> > > > > > > > Why are you asking this question on comp.lang.c?
> > > > > > >=20
> > > > > > > Because you can have it easier than with opendir() / readdir(=
).
> > > > > >=20
> > > > > > Personally, I'd use nftw to iterate over a path.
> > > > > >=20
> > > > > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw=
..html
> > > > >=20
> > > > > That would be much nicer with a lambda which can take the context
> > > > > of the calling function.
> > > > >=20
> > > >=20
> > > > That's a matter of opinion.
> > >=20
> > > It results in much less code.
> >=20
> > That is illusion, particularly in this case (about directory).
>=20
> I've shown the code. In C++17 iterating through a single directory and
> printing it is two lines of code.

C has to deal with hardware, that is all the basic (C++ and other languages=
 are
fundamentally the same).
There are 'tons' of details to consider, e.g. in multi-user/tasking conditi=
on.

> > Most serious programs will 'invent' their own functions, even their own
> > 'sugar syntax'...
>=20
> Not to iterate through a directory in C++.
>=20
> > 'sugar syntax'... result would be better than 'directory_iterator'.
>=20
> Why ?

There are many kinds of 'sub-languages' that can do any specific job better=
..
As said, C is the basic. Actually, IMO, C++ could be better than C, but C++
invented 10 times more possibility of doing things wrong (because most are
duplications).

> > In general, no need for such things as 'directory_iterator' in C-librar=
y.
>=20
>=20
> In C you're forced to write ten times the code if you include error
> handling.

C++ is no better, probably worse. Firstly, the term 'exception' (and
'vector' probably) is disabled in human mind to think about exception.
C++ had been trying to HIDE error (exception) from its beginning, very wron=
g
and very unsuccessful.

Snipet from https://sourceforge.net/projects/cscall/files/MisFiles/ClassGui=
delines.txt/download
-------- Returning error and the error checking
 Error (branching point information) not handled is always a hiden 'UB' wai=
ting
 to happen. The guideline is: ALWAYS CHECK THE ERROR. This guideline extend=
s to
 API, therefore, "__attribute__((warn_unused_result))" should be added to t=
he
 returning Errno. As usual, exception exists.

 From function usage point of view: The general concern of error checking m=
ay
 be the complexity and readibility of the source codes. In this guidelines'
 view, without the checking and handling of the error, the evaluation
 (readibility, beauty,..) of the codes is one-sided judgement, because erro=
r
 checking and handling is part of the complete program or (function). The A=
PI
 can always move the 'unwelcome' one to somewhere, but the machine sees
 everything.
 The minimum check-and-throw pattern is better than ignoration, such coding
 (throw) is equivalent to a blended cheap-and-better assert.
 Practice proves that error checking actually reduces software development =
and
 maintenance time, significantly.

Notice the term 'branching point', errors are merely branching points.
For a progam to be shorter/simpler as desired, how many branching points ar=
e=20
handled? What is 'convenience' based on, ignorance?

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