Mail Archives: djgpp-workers/1997/10/24/07:20:27
Eli Zaretskii wrote:
>
> On Thu, 23 Oct 1997, Vik Heyndrickx wrote:
>
> > The first problem is the nut-case inconsistent argument order.
> > movedata (srcs, srco, dsts, dsto, l)
> > dosmemget (src, l, dst)
> > memcpy (dst, src, l)
> > Practically every possible order is covered.
>
> `memcpy' is ANSI, we cannot change the order here.
That's the primary reason why I suggest to use this order consistently.
> `movedata' order of arguments is compatible with the function by the
> same name from Borland libraries. Only `dosmemXX' is DJ's invention.
So it seems to me that getting rid off movedata is not an option.
> > But, it seems hard to memorize by a newbie and also a 'not
> > so'-newbie.
>
> Newbies shouldn't mess with them. Non-newbies get their title by
> passing the test whereby they are required to remember the argument
> order by heart, so they by definition remember it ;-).
[I'm smiling right now]
Good point. Although newbies don't always do what they should do...
> > I propose to use the memcpy order.
> I think it will break a lot of code (or require a libc rewrite).
I will do the libc rewrite. But that is very limited in number of
changes.
> You
> could of course add new functions with different names, but I think
> this will only add to confusion (too many functions that do the same).
Agreed.
> > why is that such a problem? Well, movedata requires a pointer to be
> > casted to an int by the user. I don't like that.
>
> They only have to cast if they want to compile with -Wall and don't
> like the warnings. Otherwise, if they include the header it should
> compile without a cast. Doesn't it?
Some people do *like* to compile with -Wall. Suggesting not to use a
cast is even more evil than requiring to use one.
> > And the user has to
> > specify _my_ds() as a parameter. I don't like that either. After all %ds
> > or %es needn't get reloaded after all by the processor.
>
> `movedata' can be used to move between two segments neither of which
> is your DS. For example, imagine moving data between two
> memory-mapped devices.
And this is the only case in which it is sometimes required to reload
two segment registers.
> `movedata' should be used for large buffers, where the overhead of the
> DS reload is negligible. If they need to move small buffers, they
> should use `_farnspokeXX' which done't reload DS/ES.
I'm curious what happens when buffering is off and the user tries to
read a character from a file stream.
> > The segments that are now part of _dos_ds could get their own
> > descriptor, assigned by the startup code. Using a separate descriptor
> > for each of them has advantages.
> > I think about:
> > - The transfer buffer
> > - The video segment for the primary screen
> > - The video segment for the secondary screen
> > - maybe the BIOS data segment
>
> Is this good enough a reason to justify the code bloat? After all,
> creating such a selector is only a bunch of code lines, and even the
> FAQ shows how to do that.
Descriptors are useful as rudementary debugging tool (memory limit
control)
The code needed to implement this is very small (I preliminary think
zero bytes of code and about 8 bytes of data)
> And most people who are lazy use nearptrs
> anyway.
!(All people == most people who are lazy)
Bye.
--
+----------------+
| Vik Heyndrickx |
+----------------+
- Raw text -