On 08.08.19 10:05, Jan Beulich wrote:
Hi Jan
(I'm sorry if you receive duplicates of this, but I've got a reply
back from our mail system that several of the recipients did not
have their host names resolved correctly on the first attempt.)
Absolutely no problem.
Jan, how this could be te
(I'm sorry if you receive duplicates of this, but I've got a reply
back from our mail system that several of the recipients did not
have their host names resolved correctly on the first attempt.)
On 07.08.2019 20:36, Oleksandr wrote:
>> There's one more thing for the re-alloc case though (besides
On 07.08.2019 20:36, Oleksandr wrote:
There's one more thing for the re-alloc case though (besides
cosmetic aspects): The incoming pointer should also be verified
to be of correct type.
Jan, how this could be technically implemented, or are these any existing
examples in Xen?
See x86's copy_
Hi, Jan, Volodymyr.
c. re-allocate struct with flexible buffer.
option c. is about structures like this:
struct arrlen
{
size_t len;
int data[1];
};
This is Oleksandr's case.
So for option a. we can use _xreallocate(ptr, size, align)
For option b. we can use xrealloc_ar
Hi,
Nevertheless
I'd appreciate if the type-unsafe _xrealloc() didn't remain the
only re-allocation construct, as to avoiding people using it just
because there's no better alternative.
I got your point.
--
Regards,
Oleksandr Tyshchenko
___
Xe
On 06.08.2019 21:51, Volodymyr Babchuk wrote:
Hi Jan,
Jan Beulich writes:
On 02.08.2019 18:39, Oleksandr Tyshchenko wrote:
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -610,6 +610,27 @@ void *_xzalloc(unsigned long size, unsigned long align)
return p ? memset(p,
On 06.08.2019 20:50, Oleksandr wrote:
On 05.08.19 13:02, Jan Beulich wrote:
I can't
see though how a type-safe "realloc" could look like, except for
arrays. If resizing arrays is all you're after, I'd like to
recommend to go that route rather then the suggested one here. If
resizing arbitrary ob
Hi Jan,
Jan Beulich writes:
> On 02.08.2019 18:39, Oleksandr Tyshchenko wrote:
>> --- a/xen/common/xmalloc_tlsf.c
>> +++ b/xen/common/xmalloc_tlsf.c
>> @@ -610,6 +610,27 @@ void *_xzalloc(unsigned long size, unsigned long align)
>> return p ? memset(p, 0, size) : p;
>> }
>>
>> +void *
On 05.08.19 13:02, Jan Beulich wrote:
Hi, Jan
While I can see why having a re-allocation function may be handy,
explicit / direct use of _xmalloc() and _xzalloc() are discouraged,
in favor of the more type-safe underscore-less variants.
took into account
I can't
see though how a type-safe
On 02.08.2019 18:39, Oleksandr Tyshchenko wrote:
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -610,6 +610,27 @@ void *_xzalloc(unsigned long size, unsigned long align)
> return p ? memset(p, 0, size) : p;
> }
>
> +void *_xrealloc(void *p, unsigned long new_siz
10 matches
Mail list logo
