www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1996/04/14/13:01:55

Date: Sun, 14 Apr 1996 19:00:51 +0200
Message-Id: <199604141700.TAA27562@tyr.diku.dk>
From: Morten Welinder <terra AT diku DOT dk>
To: djgpp-workers AT delorie DOT com
In-reply-to: <199604141648.MAA23680@delorie.com> (dj@delorie.com)
Subject: Re: new write.c

   > What are the chances of the transfer buffer _not_ being aligned
   > on a paragraph?  Aren't we just wasting time doing "& 15" all
   > other the library?

   I'd rather not assume that, even if it is true.  Some rogue program
   (gdb?)  may move the transfer buffer out of the way, and not align it.

Could be.  Given that an unaligned transfer buffer is a _bad_
idea it could also be argued that complete disaster right away
would be better.  Then again, "if it ain't broke don't fix it."

   > Another thing: is it valid for _any_ library function to call
   > malloc?  If it is, then how about "...any library function
   > that would have been a syscall under Unix"?

   write() was a special case for emacs, which write()s the file out but
   has a special malloc that may move your buffer out from under you
   whenever you call it.

Here I am arguing that Emacs is not a special case.  It is just
another program that happens to define a function called malloc().
Is this allowed to change the semantics of library functions?
[probably yes].  Is it allowed to change the semantics of
"syscalls"?  [probably no]

library calls: printf, fopen, ...
syscalls: write, open, ...

On msdos the distinction is, of course, not razor blade sharp.

Morten

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019