Date:Tue, 25 Sep 2018 08:44:59 +
From:Emmanuel Dreyfus
Message-ID: <20180925084459.gd25...@homeworld.netbsd.org>
| What a pity they do that without introducing basename_r().
If that existed in some kind of wodespread use, that might have happened,
otherwise,
> But there's nothing in that bit that implies (to me!)
> "You can't subsequently call dirname(3) on the results of
> a previous call to dirname(3)".
You are calling dirname() on an argument that may be destroyed by
that very call.
You are calling dirname() on a possibly invalid argument.
Edgar =?iso-8859-1?B?RnXf?= wrote:
> > or are we restricted by some standard from having dirname(3)
> > be able to be called on the results of a previous dirname(3) call
> Not exactly restricted from, but
> This is not strictly a bug; it is explicitly allowed by
> IEEE Std
Date:Tue, 25 Sep 2018 16:32:03 +1000
From:Simon Burge
Message-ID: <20180925063203.2b92920...@thoreau.thistledown.com.au>
| Is the correct fix to use memmove(3) instead of memcpy(3) inside
| dirname(3), or are we restricted by some standard from having dirname(3)
> or are we restricted by some standard from having dirname(3)
> be able to be called on the results of a previous dirname(3) call
Not exactly restricted from, but
This is not strictly a bug; it is explicitly allowed by
IEEE Std 1003.1-2001 (``POSIX.1'').
> in which case we
Hi folks,
Should you be allowed to call dirname(3) on the results of a previous
dirname(3) call?
On NetBSD 8:
thoreau 49994> cat dirtest.c
#include
#include
#include
#include
int
main(void)
{
char *p =
