Re: Re: Pragmatic Requirements Summary : update

"Aryeh M. Friedman" <[email protected]> Mon, 4 Aug 2003 00:57:39 -0400 (EDT)
Newsgroups gmane.comp.programming.pragmatic
Message-ID <[email protected]>
> On Sun, 3 Aug 2003, Aryeh M. Friedman wrote:
> 
> > > No, you don't.  You need a machanism to access physical memory locations.  
> > > For example, "peek" & "poke" in various versions of Microsoft Basic.  I'll 
> > > admit you need better mechanisms than those, but still the number of 
> > > places that need to access physical memory, even in an OS, is relatively 
> > > small.

Small back tracking here what is to stop me from having some var ptr and then
do poke(x,rand()) in those old basics.

> > 
> > 	Except for a personal dislike of giving people real power to right code
> > what is your exact problem with direct memory access?
> 
> It's a really stupid way to access data.  The vast majority of bugs in C 
> code are caused by bad pointers.  Way too many security exploits have been 
> discovered that were caused by buffer overflows (again a pointer problem) 
> and finally, memory management in C is total crap.  In the Unix world 

	Does not sound like a problem with the concept to me just a miss application
of the techinque.   We never made any claim that memory management was going to be
along the C model anyways in Pragmatic is it is associative memory for the most part
anyways.  So even with ptrs you are limited to only your local heap, this will be 
explained better in the second PAM strawman which is still in the draft stage.

> people just seem to expect that memory leaks are to be expected.  In fact, 
> Apache is deliberately set up so that each process will die after serving 
> a configurable number of requests because of problem with memory leaks, 
> particularly in the old NCSA web server.

	I have a little experience with web servers in this area the error they
made was expanding a old model beyond the breaking point not the misuse of ptrs.
I wrote a web server back in 95 or so that was almost pure ptrs, no leaks and no
security hole ever found in it that was 100 times faster then even apache today
(core algorithms not actual machine of course).

> I've been programming for over 30 years.  I've done real time systems,
> high reliablility systems, way too much minicomputer assembly language, C
> since before the ANSI standards came out and I've seen the same bugs
> happen over and over.  In my experience, even when working inside an OS,
> being able to access physical memory is only necessary a small fraction of
> the time.

	Just becuase someone can not use a techinique properally does not mean
it should be disallowed.  That is the whole point of the low level langs you mentioned
is get around the straight jackets of high level langauages.  In the case of Pragmatic our
goal is limit if not outright elimitate the need for such structures at the high level
but most defently not to disallow them because that then creates a certain kind of
paradigm that we want to avoid (namely we want to avoid anything that is not directly
required by the HW paradigm).

> When I first started using Perl, the things I liked about it was the 
> ability to actually use strings and the ability to easily manipulate 
> variable sized lists of data with all the garbage collection "just 
> working".  I've been using Ruby for the last year or so and, again, it 
> just lets me manipulate data so easily to solve problems.  While those 
> languages are not suited for the guts of an OS, they are well suited for 
> implimenting a large number of the utilities.

	And all that is ideal and probally the right way to do a HLL but it is not
the proper way to do a low level language... Now with associate memory like I hinted
out your limited only to your own little sandbox for leaks so the best of both worlds.
Note to other people reading this it is theortically possible to use PAM to do none
associate access but it is below even the layer of Prag-core.

> Ok, that's more ranting than I intended, but after seeing the problems 
> (including my own mistakes) of using physical memory addresses when all 
> you need are dynamic data structures I sort of thought I should speak up.

	Agreed there are other ways to do dynamic structs and such but some
of them are not implimentable without real ptrs so we must allow them, just discourage
there use.

	--Aryeh

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sO0ANB/LIdGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
pragmatic_lang-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/