home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 17058 < prev    next >
Encoding:
Text File  |  1992-11-23  |  2.6 KB  |  67 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!ocsmd!ted
  3. From: ted@ocsmd.ocs.com (Ted Scott)
  4. Subject: Allocating string space via constant (was Re: Where are literals)
  5. Message-ID: <By6tGC.CvM@ocsmd.ocs.com>
  6. Sender: news@ocsmd.ocs.com
  7. Organization: Online Computer Systems, Inc.  Germantown, Md., 20874
  8. X-Newsreader: Tin 1.1 PL5
  9. References: <27583@dog.ee.lbl.gov>
  10. Date: Mon, 23 Nov 1992 21:09:47 GMT
  11. Lines: 54
  12.  
  13. Chris Torek (torek@horse.ee.lbl.gov) wrote:
  14. : In article <By0vzy.4Ly@ocsmd.ocs.com> I wrote:
  15. : >Ok, *I'm* confused here. Does this mean that if I do something like:
  16. : > *p[1] = ' '; 
  17. : >q will now point to "A C" ??
  18. : Since p[1] is a value of type `char', *p[1] is illegal: the operand of
  19. : a unary `*' indirection operator must have type `pointer to T', for some
  20. : valid type T.
  21. Um, Er, Ah...
  22. : 
  23. : Assuming you meant
  24. :     p[1] = ' ';
  25. Thanks for DWIM!
  26.  
  27.  
  28. The reasons for my question was that I have run accross *alot* of code
  29. that allocates buffers as:
  30.  
  31. char *foo ="This string constant looks big enough to hold the *REAL* data";
  32.  
  33. and then goes on to muck with the contents of foo! I hadn't realized 
  34. the inherent dangers of this practice, and apparently neither did 
  35. Mitchell Waite and Steven Prata when they wrote their primer. (p416)
  36. (Yes I know what primers are *for*) They say only that the storage 
  37. obtained with this mechanism is static, nothing aobut it may be part
  38. of a read-only segment.
  39.  
  40. Probably other C authors haven't explored these corners as well.
  41.  
  42. : >or will the above assignment yield a SEGV? or what? (I know probably what :)
  43. : Yes, `or what' :-) .  In ANSI C, the effect is explicitly undefined;
  44. : *anything* can happen.  Your computer might suddenly quote King Lear
  45. : (`old Tom's a-cold!'). 
  46. I can only hope ;)
  47.  
  48. : <Really good explanation of why this is a bad thing deleted>
  49.  
  50. This really seems to me to be a design error in the language, or the Standard.
  51. Can someone in the know explain how this came about? I mean that if I declare
  52. two seperate pointers to an initialization string that coincedentally are 
  53. identical I may or may not end up aliasing one of them, depending on the
  54. mood of the compiler writer, or maybe even the linker developer. 
  55.  
  56. Further, it is quite possible that two occurrences of the same program
  57. that share code space under a multitasking OS could point to the same memory
  58. because they share the same string initializer! What a Feature!
  59.  
  60. IOCC here I come ... <to the tune of Calif. here I come>
  61.  
  62. --
  63.  
  64. -Ted Scott          
  65. tscott@ocsmd.ocs.com           I was told that I'm a P.C. person:
  66. (301) 601-2252                               Politically Challenged, that is.
  67.