Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <34549F8C.44EB@rug.ac.be>
Date: Mon, 27 Oct 1997 15:05:00 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>, DJ Delorie <dj AT delorie DOT com>,
        Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, sandmann AT clio DOT rice DOT edu
Cc: djgpp-workers AT delorie DOT com
Subject: Re: proposal: movedata, dosmemget, etc. replacement
References: <344F2649 DOT 5B48 AT rug DOT ac DOT be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi workers,

As there are too many objections against the new set of memory copy
routines I propose, I won't make these modifications. Obviously too much
code would get broken. Having a second set of functions next to the
available ones, will get users confused, what is obviously the contrary
of what I tried to do.

What concerns the prototypes of dosmemget/put movedata, I still am
convinced that changing the type of offsets from 'int' to 'long
unsigned' is a good idea, both because the current implementation is not
consistent and it may lead to subtle (unsigned-signed) problems. When
the user doesn't want to use the correct type, well, that's his choice,
but when he wants to use the right type, he shouldn't be punished
because the type was once set to 'int' and it will remains that way. I
am aware of the fact that dosmemget and dosmemput get only 21 bits
offsets, but having an int instead of unsigned long doesn't limit the
access area at all, so that's no argument for not changing it.

What concerns the introduction of some new selectors, since I don't get
any objections except for conservative reasons, I will make these
changes, and make patches available, so you all will be able to see that
they are a good thing (that's what I hope, anyway). What I expect is
that libc will even get some bytes smaller because of these changes.

Bye.

-- 
+----------------+
| Vik Heyndrickx |
+----------------+