home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / linux / 22061 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.8 KB  |  75 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: IMPORTANT [BUG in 0.99] Re: [ANNOUNCE]: linux version 0.99
  5. Message-ID: <9236507.10435@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1992Dec19.222324.22106@klaava.Helsinki.FI> <1hpsasINN6e@meaddata.meaddata.com>
  9. Date: Tue, 29 Dec 1992 20:21:30 GMT
  10. Lines: 63
  11.  
  12. sdw@meaddata.com (Stephen Williams) writes:
  13.  
  14. >Lars Wirzenius (wirzeniu@klaava.Helsinki.FI) wrote:
  15. >: >Just curious - I haven't got the .99 sources yet, but why is an explicit
  16. >: >initialiser needed here. A static pointer ought to be initialised to
  17. >: >NULL in the executable already? 
  18. >NOT!
  19.  
  20. You are incorrect here. Ansi C guarantees that static variables are
  21. initialized.
  22.  
  23. >: 
  24. >: In normal C programs, yes, but the kernel is a bit special.  Like, for
  25. >NOT!
  26.  
  27. You are incorrect here also.
  28.  
  29. >: instance, who is going to do the initialization?  Normally it is the
  30. >: kernel (which zeroes out all memory before it is given to a user
  31. >: process), the linker (which loads the pre-initialized variables from a
  32. >: file, i.e. those variables which are given an explicit initializer),
  33. >: and possbily the C startup code.  Trouble is, none of these are active
  34. >: when the kernel is booting...
  35. >
  36. >Statics are either explicitly initialized or they are not.
  37. >If they are not, their contents are UNDEFINED until set.
  38. >This is per ANSI C.
  39.  
  40. Wrong.
  41.  
  42. >There is NO requirement of the compiler or system to zero
  43. >un-initialized statics (or auto's).
  44.  
  45. Wrong.
  46.  
  47. >The fact that some systems waste time doing so is no reason rely on it
  48. >as a feature.  This was already debated and tossed out as something to
  49. >rely on.
  50.  
  51. For all multi-user operating systems (like Linux ;-), the operating
  52. system must in general initialize the memory for security reasons.
  53. Thus it is not time wasted.
  54.  
  55. (Otherwise you could go snooping about in the unitialized memory, looking
  56. for confidential data stored there by the previous inhabitant. See
  57. the recent article in comp.risks about the Risk of leaving confidential
  58. data in memory on DOS machines.)
  59.  
  60. [lots of extremely non-portable suggestions deleted]
  61. >
  62. >And, yes, it would be nice if the nulling were garunteed.  The problem
  63. >I think is the overhead incurred for a program that has a huge bss and
  64. >doesn't need it initialized.  A better solution would be (if it
  65. >weren't for the headache..) to have bss and bsz segments.
  66.  
  67. As noted above, the initialization *is* guaranteed, and it is *not*
  68. unnecessary overhead.
  69.  
  70. -- 
  71. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  72. This .signature virus is a self-referential statement that is true - but 
  73. you will only be able to consistently believe it if you copy it to your own
  74. .signature file!
  75.