Date:Wed, 26 Sep 2018 16:42:27 + (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Well, it will return the wrong results... so might as well change the
| memcpy to memmove? No?
The results would not have been wrong - this was purely a SSP
Date:Wed, 26 Sep 2018 16:42:27 + (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Well, it will return the wrong results... so might as well change the
| memcpy to memmove? No?
That would certainly not do any harm, but it would still be better
In article <20180926124258.ga14...@homeworld.netbsd.org>,
wrote:
>On Tue, Sep 25, 2018 at 04:32:03PM +1000, Simon Burge wrote:
>> Should you be allowed to call dirname(3) on the results of a previous
>> dirname(3) call?
>
>This is about minidlna, right? if it works, please feel free to add
m...@netbsd.org wrote:
> On Tue, Sep 25, 2018 at 04:32:03PM +1000, Simon Burge wrote:
> > Should you be allowed to call dirname(3) on the results of a previous
> > dirname(3) call?
>
> This is about minidlna, right?
Yes, minidlna.
> if it works, please feel free to add
> SSP_SUPPORTED= no
> to
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 =
10 matches
Mail list logo