TIP: Click on subject to list as thread! ANSI
echo: c_echo
to: JOHN DUMAS
from: GEORGE WHITE
date: 1998-03-25 15:48:00
subject: Re: AVOID DISASTER

Hi John,
You wrote to me:
JD> JD> CB> you aren't supposed to know how it does it.  (In fact, it can, 
nd
JD> JD> This contrary to every other part of the language.
JD> GW> ?????
JD> GW> It is consistant with every other part of the standard library in my
JD> GW> experience. There is _nothing_ anywhere that defines that a standard
JD> GW> library function has to be written in a certain way, just that it has
JD> GW> to take certain parameters, perform a specified operation and
JD> GW> return/set specified results and return/set specified error 
onditions
JD> GW> values.
JD> Because of the very nature of C the functions are just not used like
JD> constructing a sentence as in some other languages.
JD> The inputs type,length,limets, as well as, the same for the output and 
he
JD> way the functions operate are in my library reference books as well as
I thought that was what I said!
JD> a lot of examples of how these functions are written as in "Craft of C"
JD> and other books and information to an extent that I ( in my "limeted"
JD> observations of other languages) have not yet seen matched.
But the examples of how these things are done is outwith the language
specification, which as we both agree is tight on parameters and return
values.
JD> What I an basically saying is C is highly documented and explained
JD> compared to other languages and the inscrutability and non-excess
JD> of the memory alocation proccess is not consistant with the rest of
JD> the language.
This is where we'll have to agree to disagree. I believe the memory
handling functions are as well documented as the rest of the standard
library functions, and for them to be tied down as to methods used would
be against the spirit of the language. The techniques used have to be
able to vary depending on the target OS platform. The techniques used
for MS/PC/DR DOS (usually a linked list) will not always be appropriate
for an embedded system (where memory is usually constrained and may not
even be available as a contiguous block); multi-tasking OSs with virtual
memory require different techniques (usually an initial allocation from
the system, with extra memory taken as more heap is required);
multi-threaded programs (such as OS/2 supports) provide yet a another
set of constraints for memory allocation.
George
 * SLMR 2.1a * Wastebasket: Something to throw things near.
--- Maximus/2 3.01
---------------
* Origin: DoNoR/2,Woking UK (44-1483-717905) (2:440/4)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.