Re: mremap prototyp

[Jakub Jelinek <jakub at redhat dot com>]

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