home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.linux.misc      Linux-specific topics not covered by oth      135,536 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 135,251 of 135,536   
   The Natural Philosopher to All   
   Re: Memory Safety (Re: Python: A Little    
   06 Feb 26 10:42:51   
   
   From: tnp@invalid.invalid   
      
   On 06/02/2026 01:48, c186282 wrote:   
   > On 2/5/26 09:14, The Natural Philosopher wrote:   
   >> On 05/02/2026 13:45, Lars Poulsen wrote:   
   >>> On 2026-02-04, c186282  wrote:   
   >>>>     Being able to pass pointers back and forth is   
   >>>>     a strong point with 'C'. In theory this COULD   
   >>>>     be exploited by evil actors, but I can't find   
   >>>>     any clear doc on whether it's been done to   
   >>>>     any relevant degree. Most security probs result   
   >>>>     from developer stupidity, not from the underlying   
   >>>>     language and methods.   
   >>>>   
   >>>>     Amazing how many still allocate mem, or even   
   >>>>     just string space or use thereof, without the   
   >>>>     slightly newer functions that let you specify   
   >>>>     just HOW many bytes are involved. "Buffer   
   >>>>     overflow" is still a prime attack vector. Keep   
   >>>>     seeing it in M$ warning notes and no doubt   
   >>>>     there's similar idiocy in Linux/UNIX apps   
   >>>>     as well.   
   >>>   
   >>> This was the great thing about i286 protected mode.   
   >>> It was trivial to substitute a malloc()/free() pair where   
   >>> malloc()'ed structures were segment that would trap any buffer   
   >>> overflows.   
   >>>   
   >>>   
   >> C memory issues seem to amount to two things only.   
   >>   
   >> Use of local buffers which may get overrun and then smash the stack...   
   >> mismatched allocation and de allocation of memory by library   
   >> functions. Leading to overwrites, memory segfauilts or memory leaks.   
   >>   
   >> The first is of course implementation specific. C can specify a data   
   >> stack separate from a program stack and avoid code corruption, leaving   
   >> only data corruption...   
   >>   
   >> And today's hardware is RAM loaded. Programmers merely need avoid   
   >> dynamic allocation of memory, altogether.   
   >   
   >   
   >    Are we to go back to static arrays then ?   
   >    What happens when you need a hundredth   
   >    and ONE of something ?  :-)   
   >   
   You rewrite your code to accomodate reality.   
     and get fired for not anticipating the problem and dealing gracefully   
   with a suitable error message..   
   "someone is trying to overwrite my buffer"   
      
   Ah the good old days of DIS and sco unix with just 10 file buffers and a   
   similar mumler of telnet sessions...   
      
   --   
   "It was a lot more fun being 20 in the 70's that it is being 70 in the 20's"   
   Joew Walsh   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca