mremap prototyp
Jakub Jelinek
jakub@redhat.com
Wed Apr 3 07:47:00 GMT 2002
On Wed, Apr 03, 2002 at 04:38:44PM +0100, Philip Blundell wrote:
> On Wed, 2002-04-03 at 16:29, Andreas Jaeger wrote:
> >
> > Andi noticed that our mremap implementation is not correct.
> >
> > The Linux kernel implements mremap as:
> >
> > asmlinkage unsigned long sys_mremap(unsigned long addr,
> > unsigned long old_len, unsigned long new_len,
> > unsigned long flags, unsigned long new_addr)
> >
> >
> > But we have:
> > extern void *mremap (void *__addr, size_t __old_len, size_t __new_len,
> > int __may_move) __THROW;
> >
> > What shall we do? Add the fifth argument everywhere? Can we just
> > change the interface in glibc?
>
> The existing implementation is correct, it just doesn't support the full
> semantics that the kernel provides. You can't change it as this will
> break all existing software. The right thing to do if people actually
> want to use this extended interface would be to add some kind of new
> mremap2 function that allows you to pass in "new_addr".
Um, why you cannot declare
extern void *mremap (void *__addr, size_t __old_len, size_t __new_len,
int __flags, ...) __THROW;
(and export it at GLIBC_2.3, so that software using the new mremap will
not be able to link against old glibc)?
glibc would just check if __flags & MREMAP_FIXED, if yes, va_arg() new_addr,
otherwise nothing.
Jakub
More information about the Libc-alpha
mailing list