home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / amiga / programm / 17224 < prev    next >
Encoding:
Internet Message Format  |  1992-12-11  |  2.3 KB
  1. Path: sparky!uunet!ogicse!emory!gatech!concert!sas!mozart.unx.sas.com!walker
  2. From: walker@twix.unx.sas.com (Doug Walker)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: SAS6.1 users: please read
  5. Message-ID: <Bz3zxI.2A8@unx.sas.com>
  6. Date: 11 Dec 92 19:10:30 GMT
  7. Article-I.D.: unx.Bz3zxI.2A8
  8. References: <1992Dec3.005753.8826@urbana.mcd.mot.com> <Byov0y.nJ@fc.hp.com>
  9. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  10. Organization: SAS Institute Inc.
  11. Lines: 41
  12. Originator: walker@twix.unx.sas.com
  13. Nntp-Posting-Host: twix.unx.sas.com
  14.  
  15.  
  16. In article <Byov0y.nJ@fc.hp.com>, koren@fc.hp.com (Steve Koren) writes:
  17. |> It seems to me that doing an integer operation on an unsigned and a
  18. |> signed integer should always result in a signed integer.  Anybody
  19. |> understand why they picked the opposite?  Kinda like doing an operation
  20. |> on an integer and a double should yield a double.  Ie, I'd think you'd
  21. |> always promote to the most general of the types of the operands,
  22. |> regardless of their order of appearance in the equation.
  23.  
  24. But what if the unsigned number contained a value that was bigger than
  25. the signed number could represent?  If you converted the unsigned
  26. number instead, you'd have an OVERFLOW instead of an UNDERFLOW and
  27. you'd have some very large negative number involved in the operation.
  28.  
  29. ANSI chose to consider unsigned types wider than their corresponding
  30. signed types because they can represent larger numbers.  You seem to
  31. be considering signed types wider than unsigned types, from looking at
  32. your example with doubles and ints, but your term is "more general".
  33.  
  34. If you consider signed wider than unsigned, you could end up with even
  35. more confusing results.  Consider the following:
  36.  
  37.    unsigned int x = 0x7fffffff;
  38.  
  39.    if(x+1 > 0x7fffffff)
  40.    {
  41.       printf("Ok\n");
  42.    }
  43.  
  44. Does the "if" condition come out true or false?  In this case, it
  45. comes out true if the result is "unsigned int" as ANSI states, and
  46. false if the result is "int" as you are suggesting.
  47.  
  48. -- 
  49.   *****
  50. =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
  51.  *|. o.| ||                                          1200/2400/9600 Dual
  52.   | o  |//     For all you do, this bug's for you!
  53.   ====== 
  54. usenet: walker@unx.sas.com                            bix: djwalker 
  55. Any opinions expressed are mine, not those of SAS Institute, Inc.
  56.