Date:Wed, 25 Mar 2020 20:59:59 -0400
From:Greg Troxel
Message-ID:
| I'll fourth this sentiment.
Me too (5th...)
The idea that /tmp is smaller than /var/tmp (or has less available space)
is based upon historic RAM sizes, my /tmp currently has about 10 times
as
Date:Wed, 25 Mar 2020 20:51:25 +
From:David Holland
Message-ID: <20200325205125.ga11...@netbsd.org>
| I don't agree -- because applications shouldn't attempt to modify the
| result, it should be const.
The only reason apps shouldn't modify the string is in
Taylor R Campbell writes:
>> Do we insist on this patch? Can we remove it from local sources?
>
> We should keep the change. There is no semantic justification for
> putting build-time temporary files in the directory for temporary
> files that are meant to persist across reboot. These
> Date: Thu, 26 Mar 2020 01:26:05 +0100
> From: Kamil Rytarowski
>
> Upstream (GCC) is strongly against this change (even under __NetBSD__
> ifdef) as /var/tmp is typically larger than /tmp:
>
> > I'd strongly recommend against this as-is.
> >
> > The whole reason we prefer /var/tmp is because
We (to the extent I can assert that as an individual developer) insist
on keeping it.
Jonathan Kollasch
On Thu, Mar 26, 2020 at 01:26:05AM +0100, Kamil Rytarowski wrote:
> Upstream (GCC) is strongly against this change (even under __NetBSD__
> ifdef) as /var/tmp is typically larger than
> On Mar 25, 2020, at 5:26 PM, Kamil Rytarowski wrote:
>
> Upstream (GCC) is strongly against this change (even under __NetBSD__
> ifdef) as /var/tmp is typically larger than /tmp:
>
>> I'd strongly recommend against this as-is.
>>
>> The whole reason we prefer /var/tmp is because it's often
Upstream (GCC) is strongly against this change (even under __NetBSD__
ifdef) as /var/tmp is typically larger than /tmp:
> I'd strongly recommend against this as-is.
>
> The whole reason we prefer /var/tmp is because it's often dramatically
larger
> than a ram-backed /tmp.
-- by Jeff Law.
Do we
On Wed, Mar 25, 2020 at 06:50:47PM +, Robert Elz wrote:
> Modified Files:
> src/lib/libc/string: strerror.3
>
> Log Message:
> Delete the BUGS paragraph about the "missing" const qualifier for the
> result type of strerror() (and strerror_l()). While that once should
> really
Date:Tue, 24 Mar 2020 19:37:02 +0100
From:Kamil Rytarowski
Message-ID: <57a7e062-9af0-0be9-cb24-e155c5f83...@gmx.com>
| ASan detects not a hypothetical, but factual momory corruption.
Yes, I know that - and I believed you from the start that there was a
buffer
