Re: Changing basename(3) and dirname(3) for future posix compatibility

2017-12-12 Thread Robert Elz
Date:Tue, 12 Dec 2017 11:04:41 +0100 From:Joerg Sonnenberger Message-ID: <20171212100441.ga32...@britannica.bec.de> | Effectively requiring modifyable input for basename(3) is highly | annoying and breaks legacy code. Are you talking of just

Re: Changing basename(3) and dirname(3) for future posix compatibility

2017-12-12 Thread Joerg Sonnenberger
On Sun, Dec 03, 2017 at 07:57:58AM +0700, Robert Elz wrote: > The next POSIX update (issue 8 of whatever it is called in the wild) - that > is the next "minor corrections" update, as distinct from the next major > update, is planning on (if I follow correctly, has already decided) to > tighten the

Re: Changing basename(3) and dirname(3) for future posix compatibility

2017-12-03 Thread Robert Elz
Date:Sun, 3 Dec 2017 12:36:00 +0100 From:Edgar =?iso-8859-1?B?RnXf?= Message-ID: <20171203113600.gl4...@trav.math.uni-bonn.de> | Has anyone scanned NetBSD's (or pkgsrc's) codebase for such uses? I am in the process of doing that - that's

Re: Changing basename(3) and dirname(3) for future posix compatibility

2017-12-03 Thread Edgar Fuß
> there might be NetBSD applications currently which are assuming > that the input string is not modified by these functions I'd be heavily surprised if that change wouldn't break half (OK, 10%) the consumers, either because they call both functions on the same path argument or because they

Changing basename(3) and dirname(3) for future posix compatibility

2017-12-02 Thread Robert Elz
The next POSIX update (issue 8 of whatever it is called in the wild) - that is the next "minor corrections" update, as distinct from the next major update, is planning on (if I follow correctly, has already decided) to tighten the definitions of basename(3) and dirname(3) in order to make it