home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8457 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  2.6 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!swrinde!elroy.jpl.nasa.gov!ames!riacs!news
  2. From: laredo@cc.gatech.edu (Nathan I. Laredo)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: shared libs - can everyone be happy with this?
  5. Message-ID: <1992Aug17.152210.23427@riacs.edu>
  6. Date: 17 Aug 92 15:22:10 GMT
  7. References: <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> <1992Aug17.065450.28834@colorado.edu> <d-dyhz_@rpi.edu>
  8. Sender: news@riacs.edu
  9. Organization: Georgia Institute of Technology
  10. Lines: 35
  11.  
  12. In article <d-dyhz_@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
  13. >In article <1992Aug17.065450.28834@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
  14. >|> In article <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> nop@theory.Mankato.MSUS.EDU (Jay A. Carlson) writes:
  15. >|> >In article <1992Aug15.042420.18914@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes:
  16. >    [Stuff Deleted] 
  17. >|> Also, if we ever unbreak Linux, writing to code space should trigger
  18. >|> a segmentation fault - it's like it is now because the estdio library 
  19. >|> was broken, and wrote to the code. 
  20. >    Does linux permit self modifying code (by design or bug)?
  21. >    This seems like a pretty bad ``feature''.
  22.  
  23. Hopefully we won't start another nasty chain here.. but someone correct
  24. me if I'm wrong, but I've always been from the school that said that
  25. all static variables went into the code space, otherwise how would
  26. they be loaded in.  If one cannot modify the code space then I would
  27. see it as impossible to modify a static variable.   In effect when you
  28. declare something static and you modify it, haven't you modified your
  29. code?   If we lost this ability, then I would see it as quite tricky
  30. to implement static declarations with some elaborate loader that would
  31. have to be implemented.  As it stands, design is simplified, and there
  32. is no sacrifice in execution speed.   If a programmer wants to modify
  33. his code or store values within the code, we should let him.   There's
  34. only one reason to protect that, and it's to protect the programmer from
  35. himself or herself.   Any programmer that intentionally modifies something
  36. in code space will most probably know what is going on.  As to integrity
  37. issues, if you make it to break, it's your fault.
  38.  
  39. Yeah, it's not the best view, but it's the way I see things.   I don't
  40. want to start any long debates on the issue, so if you disagree with me,
  41. reply by email.  "Oh I love mail" - The Count, Sesame Street.
  42. --
  43. Nathan I. Laredo (this spot: $9) Internet: gt7080a@prism.gatech.edu 
  44. uucp:  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7080a
  45. "Having had the correct view is nothing meritorious: statistically,
  46.  it is almost inevitable..."  -- Mr. Palomar,  On biting the tongue
  47.