allocation functions: pass size to XREALLOC and XFREE

[minad]

This is similar to the signatures of the custom allocation functions provided by GMP.
The allocation sizes are useful if the allocator has no easy way to access the allocation size.

[sjaeckel]

phew ... I like the idea, but I also had cases in the past where it was useful that those macros don't have arguments... on the other hand, in that case one could still modify those parts...

TBH what I don't like is that realloc has first oldsize and then newsize! That confused me when looking at the patches for the first time. I would've expected to have "the additional argument" being prepended, not stuffed in the middle.

[minad]

TBH what I don't like is that realloc has first oldsize and then newsize! That confused me when looking at the patches for the first time. I would've expected to have "the additional argument" being prepended, not stuffed in the middle.

I just used the GMP convention. I think it also makes more sense. realloc and free are aligned. First mem, then size and realloc gets one additional size argument.

[minad]

phew ... I like the idea, but I also had cases in the past where it was useful that those macros don't have arguments... on the other hand, in that case one could still modify those parts...

What use case was that? I wonder what you could do that you cannot if this patch is applied.
But in the end you have to decide which use case makes more sense.

As a datapoint, I have to patch tommath in my project right now since I need those sizes due to the primitive bump allocator I am using. In particular realloc makes problems since there I need the old size to compare and to perform the memcpy.

[sjaeckel]

What use case was that?

memory-leak checking on an embedded device... but that doesn't matter anymore :-)

the more important question is now regarding the order of the 2 size arguments to realloc, has it to be like that? it feels not natural to me the way it's done now.

[minad]

Why would that leak checking not work with the new macros? But if it does not matter it does not matter. No need to discuss.

Concerning the order - I have three arguments in favour of the order (mem, old, new):

1. GMP does it that way and people might want to switch between the two libs (at least I do)
2. I see (mem, size) as a tuple since each allocated memory block has a size. If you use the convention realloc(mem, new, old), this does not hold anymore.
3. free and realloc are aligned and take the arguments in the same order.

And one against:

1. standard libc realloc signature takes (mem, newsize). Given this PR, the middle argument is omitted which you find unnatural.

But in the end I don't really care and I would like to avoid bikeshed discussions :)

[sjaeckel]

Okay, accepted :)

can you please rebase

[minad]

done

[minad]

@sjaeckel rebased again

[minad]

@sjaeckel merge conflicts solved and rebased

[sjaeckel]

zomg I couldn't merge even if I would, which I don't.

[sjaeckel]

@sjaeckel merge conflicts solved and rebased

zomg I couldn't merge even if I would, which I don't.

oh, I wasn't fast enough to hit 'Comment'

[minad]

Unfortunately my "just merge if clean merging is possible comment" didn't apply here ;)