home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / linux / 17042 < prev    next >
Encoding:
Text File  |  1992-11-17  |  1.9 KB  |  38 lines
  1. Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!fs7.ece.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!fl0p+
  3. Newsgroups: comp.os.linux
  4. Message-ID: <Af2Lgoa00VpdEMjkgq@andrew.cmu.edu>
  5. Date: Tue, 17 Nov 1992 18:07:32 -0500 
  6. From: Frank T Lofaro <fl0p+@andrew.cmu.edu>
  7. Subject: Read-only text segments (was minicom breaks under 0.98pl5)
  8. Lines: 28
  9.  
  10. From comp.os.linux: 17-Nov-92 Re: minicom broken under .98-5 Brent
  11. Benson@ssd.csd.harris.com (712)
  12.  
  13. >You don't have to go to such lengths to do this sort of thing.  Simply
  14. >use an initialized array of characters rather than a pointer to a
  15. >string constant:
  16.  
  17. >char gname[] = "stuff";
  18.  
  19.     Okay, an initialized array will allow you to change the contents, but
  20. want if the program also wants to then change what gname points too? It
  21. might not work. (Yeah I know it is extremely bad code (char
  22. *gname="stuff") originally that resulted in an attempt to change a
  23. strings literal pointed to by a pointer when the pointer was later
  24. dereferenced. Nevertheless, it seems that stuff later on might depend on
  25. where gname points being changable.)
  26.  
  27. P.S. I totally agree with Linus' tightening of the restrictions
  28. (stopping NULL pointer dereferences, and now making the text-segment
  29. read-only.). It might have been necessary for rapid development to allow
  30. somewhat messy stuff to work for the time being, but with 1.0 in the not
  31. too distant future, ensuring quality programming that doesn't do
  32. anything really wrong is a good idea. That way we can be better assured
  33. of a more stable, reliable, well built OS/software enviornment. If
  34. anything breaks, it was kind of broken to begin with, and now it will
  35. get fixed, like it should. Anyway thanks for an excellent OS, and I hope
  36. that the little fixing of stuff up doesn't make the road too bumpy :)
  37.  
  38.