home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / c / 2639 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  2.1 KB
  1. Xref: sparky comp.std.c:2639 comp.lang.c:13715
  2. Path: sparky!uunet!gatech!concert!duke!dsb
  3. From: dsb@duke.cs.duke.edu (D. Scott Bigham)
  4. Newsgroups: comp.std.c,comp.lang.c
  5. Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
  6. Message-ID: <716616917@romeo.cs.duke.edu>
  7. Date: 16 Sep 92 04:15:18 GMT
  8. References: <a_rubin.716225408@dn66  <1992Sep12.16491 <1992Sep16.014635.27449@nntpd.lkg.dec.com>
  9. Followup-To: comp.std.c
  10. Organization: n. Arrangement in an orderly or logical fashion.  See "miracle".
  11. Lines: 33
  12.  
  13. From the Holy Book of <1992Sep16.014635.27449@nntpd.lkg.dec.com>
  14.   as spake by diamond@jit.dec.com (Norman Diamond) :
  15. >Yeah, and Mr. Bigham tried to trick me into posting to comp.lang.c (without
  16. >warning), so I've added comp.lang.c back in for Mr. Bigham.
  17.  
  18. Trick?  My dear sir, that's where I _found_ the article I was replying
  19. to!  Follow-ups re-redirected for your peace of mind. :)
  20.  
  21. >OK, I can find in ANSI 3.2.1.5, page 36 lines 17 to 18, "and yield result
  22. >types in a similar way.  The purpose is to yield a common type, which is
  23. >also the type of the result."
  24.  
  25. However (I take you to mean), if the product overflows the type of the
  26. result, we experience the dreaded Undefined Behavior and the compiler is
  27. free to do anything it wants, including changing the type of the result
  28. to accommodate the value of the product.  Okay, fair enough.
  29.  
  30. >Sounds like it agrees with the standard.  Sometimes the result [of cast
  31. >to int] is defined by the standard, the rest of the time the result is
  32. >defined by the implementation, and the result is never undefined.
  33.  
  34. A fine distinction, and one I'm not certain I understand.  Is the
  35. implementation required, for instance, to inform the programmer how it
  36. will behave in an "implementation-defined" situation?  Is the
  37. implementation free to define that overflow in expressions causes your
  38. computer to turn into an alligator?
  39.  
  40.                         -sbigham
  41. -- 
  42. Scott Bigham                   | The opinions expressed above are
  43. dsb@romeo.cs.duke.edu          | (c) 1992 Hacker Ltd. and cannot be
  44. bigham@hercules.acpub.duke.edu | copied or distributed without a
  45.     (but not for long)         | Darn Good Reason(tm).
  46.