On Wed, 24 Jan 2018, Conrad Meyer wrote:
On Wed, Jan 24, 2018 at 10:05 AM, Warner Losh wrote:
...
Let's start with his point about u_long vs size_t causing problems:
void*malloc(unsigned long size, struct malloc_type *type, int flags)
vs
void*mallocarray(size_t
On Wed, Jan 24, 2018 at 2:40 PM, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 1:13 PM, Warner Losh wrote:
> > mallocarray should be the last line of defense, not the only line of
> > defense.
>
> Agreed.
>
> > most of the time, it's more correct to say
> >
>
On Wed, Jan 24, 2018 at 1:13 PM, Warner Losh wrote:
> mallocarray should be the last line of defense, not the only line of
> defense.
Agreed.
> most of the time, it's more correct to say
>
> if (WOULD_OVERFLOW(a,b))
> return EINVAL;
> ptr = mallocarray(a,b...);
Disagree --
On Wed, Jan 24, 2018 at 12:40 PM, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 11:27 AM, Warner Losh wrote:
> >
> > Which is why we should add check overflows for most of the no wait cases.
> > They should be checked, but not primarily with mallocarray...
>
>
On Wed, Jan 24, 2018 at 11:27 AM, Warner Losh wrote:
>
> Which is why we should add check overflows for most of the no wait cases.
> They should be checked, but not primarily with mallocarray...
I don't understand what the distinction is here. Can you help me
understand why the
On Jan 24, 2018 12:24 PM, "Conrad Meyer" wrote:
On Wed, Jan 24, 2018 at 10:51 AM, Pedro Giffuni wrote:
> FWIW, I suggested a panic for M_WAITOK and returning NULL for M_NOWAIT,
but
> cem didn't like it because it was inconsistent.
>
> I think the current
On Wed, Jan 24, 2018 at 10:44 AM, Pedro Giffuni wrote:
> ...
> On 24/01/2018 13:30, Conrad Meyer wrote:
>>
>> ...
>> size_t can handle 10GB, but u_long can't.
>> This whole argument hinges upon incorrect assumption that size_t is
>> larger than u_long.
>
>
> Hmm...
>
> Lets just
On Wed, Jan 24, 2018 at 10:51 AM, Pedro Giffuni wrote:
> FWIW, I suggested a panic for M_WAITOK and returning NULL for M_NOWAIT, but
> cem didn't like it because it was inconsistent.
>
> I think the current argument is more about the size/trigger than the
> behavior though.
On 24/01/2018 13:40, Hans Petter Selasky wrote:
On 01/24/18 19:28, Warner Losh wrote:
Does mallocarray(10 ,1Gb) panic on i386? It does not. It should.
Hi,
If M_WAITOK is specified, then sleep forever and print a message.
Else return NULL ?
FWIW, I suggested a panic for M_WAITOK and
...
On 24/01/2018 13:30, Conrad Meyer wrote:
...
size_t can handle 10GB, but u_long can't.
This whole argument hinges upon incorrect assumption that size_t is
larger than u_long.
Hmm...
Lets just make it "unsigned long" to be consistent with malloc(9) and
avoid confusion?
Pedro.
On Wed, Jan 24, 2018 at 10:40 AM, Hans Petter Selasky wrote:
> On 01/24/18 19:28, Warner Losh wrote:
>>
>> Does mallocarray(10 ,1Gb) panic on i386? It does not. It should.
>
>
> Hi,
>
> If M_WAITOK is specified, then sleep forever and print a message.
> Else return NULL ?
On Jan 24, 2018 11:33 AM, "Conrad Meyer" wrote:
Bruce didn't get this wrong, you've just misread his (style / opinion)
complaint as an actual bug (which is kind of the whole reason why it's
hard to treat his complaints seriously):
> size_t happens to have the same
On 01/24/18 19:28, Warner Losh wrote:
Does mallocarray(10 ,1Gb) panic on i386? It does not. It should.
Hi,
If M_WAITOK is specified, then sleep forever and print a message.
Else return NULL ?
--HPS
___
svn-src-all@freebsd.org mailing list
Bruce didn't get this wrong, you've just misread his (style / opinion)
complaint as an actual bug (which is kind of the whole reason why it's
hard to treat his complaints seriously):
> size_t happens to have the same representation as u_long on all supported
> arches
So yes, the check works on
On Wed, Jan 24, 2018 at 10:05 AM, Warner Losh wrote:
> It changes the fundamental 'can't fail' allocations into 'maybe panic'
> allocations, which was my big objection.
No, it doesn't make any such change. The only calls that will panic
now would have "succeeded" before but
On Wed, Jan 24, 2018 at 11:05:24AM -0700, Warner Losh wrote:
> Let's start with his point about u_long vs size_t causing problems:
>
> void*malloc(unsigned long size, struct malloc_type *type, int flags)
> vs
> void*mallocarray(size_t nmemb, size_t size, struct malloc_type *type,
>
>
Does mallocarray(10 ,1Gb) panic on i386? It does not. It should.
Warner
On Jan 24, 2018 11:20 AM, "Conrad Meyer" wrote:
> Please point out what in Bruce's rant is actually relevant. Again, I
> usually start reading them and get sidetracked in things that are
> opinions
Please point out what in Bruce's rant is actually relevant. Again, I
usually start reading them and get sidetracked in things that are
opinions stated as fact, or outright incorrect. At which point, I
give up on them.
___
svn-src-all@freebsd.org
On 01/24/18 12:37, Conrad Meyer wrote:
On Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni wrote:
On 23/01/2018 14:08, Conrad Meyer wrote:
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision:
On Wed, Jan 24, 2018 at 10:34 AM, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote:
> > I agree completely. It doesn't do what you think it is doing, for all the
> > reasons that Bruce outlines. We thought it was a bad idea when it came
On Wed, 2018-01-24 at 09:34 -0800, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote:
> >
> > I agree completely. It doesn't do what you think it is doing, for all the
> > reasons that Bruce outlines. We thought it was a bad idea when it came up 2
> >
On 01/24/18 03:50, Bruce Evans wrote:
On Tue, 23 Jan 2018, Pedro Giffuni wrote:
On 23/01/2018 14:08, Conrad Meyer wrote:
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni
wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL:
On Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni wrote:
> On 23/01/2018 14:08, Conrad Meyer wrote:
>> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
>>>
>>> Author: pfg
>>> Date: Sun Jan 21 15:42:36 2018
>>> New Revision: 328218
>>
>> I'm confused
On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote:
> I agree completely. It doesn't do what you think it is doing, for all the
> reasons that Bruce outlines. We thought it was a bad idea when it came up 2
> years ago and nothing has really changed.
I disagree. I'm not sure
On Wed, Jan 24, 2018 at 1:50 AM, Bruce Evans wrote:
> On Tue, 23 Jan 2018, Pedro Giffuni wrote:
>
> On 23/01/2018 14:08, Conrad Meyer wrote:
>>
>>> Hi Pedro,
>>>
>>> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni
>>> wrote:
>>>
Author: pfg
On Tue, 23 Jan 2018, Pedro Giffuni wrote:
On 23/01/2018 14:08, Conrad Meyer wrote:
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL: https://svnweb.freebsd.org/changeset/base/328218
Log:
Hi;
On 23/01/2018 17:13, Bryan Drewery wrote:
On 1/23/2018 11:40 AM, Pedro Giffuni wrote:
Hi;
On 23/01/2018 14:08, Conrad Meyer wrote:
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni
wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL:
On 1/23/2018 11:40 AM, Pedro Giffuni wrote:
> Hi;
>
>
> On 23/01/2018 14:08, Conrad Meyer wrote:
>> Hi Pedro,
>>
>> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni
>> wrote:
>>> Author: pfg
>>> Date: Sun Jan 21 15:42:36 2018
>>> New Revision: 328218
>>> URL:
Hi;
On 23/01/2018 14:08, Conrad Meyer wrote:
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL: https://svnweb.freebsd.org/changeset/base/328218
Log:
Revert r327828, r327949, r327953,
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
> Author: pfg
> Date: Sun Jan 21 15:42:36 2018
> New Revision: 328218
> URL: https://svnweb.freebsd.org/changeset/base/328218
>
> Log:
> Revert r327828, r327949, r327953, r328016-r328026, r328041:
> Uses of
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL: https://svnweb.freebsd.org/changeset/base/328218
Log:
Revert r327828, r327949, r327953, r328016-r328026, r328041:
Uses of mallocarray(9).
The use of mallocarray(9) has rocketed the required swap to build FreeBSD.
This
31 matches
Mail list logo