Re: Pragmatic Requirements Summary : update

>  
> 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) 
 
 This isn't a pointer problem. Its problem in a language that doesnt check bounds. 
  
> and finally, memory management in C is total crap.  
 
 I agree. 
 
> In the Unix world  
> people just seem to expect that memory leaks are to be expected.  
 
 Maybe. Generally in applications where I can afford to I just compile in a garbage 
collector. 
 
> 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. 
 
 Thats kind of nasty. I would have expected a bit better from apache. 
  
> 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. 
 
 We agree. We just feel that when we are in that small fraction of time we really 
need it. 
 
> 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. 
 
 Our current plan, subject to modification since it is so early. Is to provide garbage 
collection and manual memory management. By default garbage collection will be 
on and available but there will be programmer facilities to disable it and manage 
memory manually. 
 
 
>  
> 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. 
>  
> -- Matt 
 
 I agree but for the reasons you specified we cant do away with it completly. 
  
 --  
> From my heart and from my hand, why don't people understand my intention? 


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/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/