home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / c / 3329 < prev    next >
Encoding:
Text File  |  1993-01-07  |  5.0 KB  |  109 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!jit533.jit.dec.com!diamond
  3. From: diamond@jit533.jit.dec.com (Norman Diamond)
  4. Subject: Re: Sequence space arithmetic
  5. Message-ID: <1993Jan7.032709.20670@nntpd.lkg.dec.com>
  6. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  7. Reply-To: diamond@jit.dec.com (Norman Diamond)
  8. Organization: Digital Equipment Corporation Japan , Tokyo
  9. References: <1ifb0pINN7qq@daisy.ee.und.ac.za>
  10. Date: Thu, 7 Jan 1993 03:27:09 GMT
  11. Lines: 96
  12.  
  13. In article <1ifb0pINN7qq@daisy.ee.und.ac.za> barrett@daisy.ee.und.ac.za (Alan P Barrett) writes:
  14. >#include <limits.h>
  15. >/* how to check if (a >= b) in 32-bit sequence space arithmetic. */
  16. >#if (UINT_MAX == 0xffffffff)            /* int is exactly 32 bits */
  17. >#        define SEQ_GT(a,b) ((int)((unsigned int)(a)-(b)) > 0)
  18. >#else
  19. >#  if (ULONG_MAX == 0xffffffff)         /* long is exactly 32 bits */
  20. >#        define SEQ_GT(a,b) ((long)((unsigned long)(a)-(b)) > 0)
  21. >#  else
  22. >#    if (ULONG_MAX > 0xffffffff)        /* long is wider than 32 bits */
  23. >#      if 1 /* if you insist on evaluating a and b exactly once each */
  24. >#        define SEQ_GT(a,b) \
  25. >                ((((unsigned long)(a)-(b)) & 0xffffffff)-1 < 0x7fffffff)
  26. >#      else /* this is more intuitively obvious */
  27. >#        define SEQ_GT(a,b) \
  28. >                (((a)!=(b)) && ((((unsigned long)(a)-(b)) & 0x80000000) == 0))
  29. >#      endif
  30. >#    else                               /* long is narrower than 32 bits */
  31. >       #error "ULONG_MAX is less than 32 bits.  Get a real compiler."
  32. >#    endif
  33. >#  endif
  34. >#endif
  35.  
  36. ANSI Classic section 3.2.1.2, page 35 lines 30 to 33:  "When a value with
  37. integral type is demoted to a signed integer with smaller size, OR AN
  38. UNSIGNED INTEGER IS CONVERTED TO ITS CORRESPONDING SIGNED INTEGER, if the
  39. value cannot be represented the result is implementation-defined."
  40.  
  41. Even on a nice friendly two's complement machine with 32-bit ints, UINT_MAX
  42. defined as 0xffffffff, INT_MAX as 0x7fffffff, and INT_MIN as -0x40000000<<1,
  43. your cast of a big unsigned int (result of subtraction) to a signed int is
  44. not guaranteed to give you what you want.
  45.  
  46. The result is equally implementation-defined for one's complement machines,
  47. but is even less likely to give you what you want.
  48.  
  49. You're better off sticking to unsigned arithmetic entirely.
  50.  
  51. >Are both methods for handling longs wider than 32 bits guaranteed to work?
  52.  
  53. I think those work.
  54.  
  55. >Will they also work with longs of exactly 32 bits? 
  56.  
  57. No, for the same reason as ints of exactly 32 bits don't.
  58.  
  59. >Which is likely to be handled better by existing compilers?
  60.  
  61. Huh?  Obviously you're not asking a standards question here, but if you're
  62. talking about conforming implementations, well they all have to handle the
  63. syntax of what you've given, and you haven't given any other choices that
  64. might be handled better or worse.  What's your question?
  65.  
  66. >I believe that casting unsigned values into signed types is implementation
  67. >defined, and that this affects the parts that handle int or long of
  68. >exactly 32 bits.  Is that the case?
  69.  
  70. Ah, then you knew.
  71.  
  72. >If we assume that the implementation does the obvious thing with
  73. >casts (just interprets the bits differently), will that code work?
  74.  
  75. Are your asking about the standard or not?
  76.  
  77. >How reasonable is it to make such an assumption, given that the code is
  78. >intended to run on a Unix system?
  79.  
  80. >Would it be reasonable to omit all the #if tests, leaving just the part
  81. >that deals with longs wider than 32 bits, and trust the compiler to make
  82. >the relevant optimisations if a 32-bit type is available?
  83.  
  84. I think it would be reasonable in the interests of getting correct results.
  85. As for optimizations...  You haven't said what types the arguments (a and b)
  86. are likely to have.  If they're longs, then unsigned long arithmetic should
  87. be expected, and is unlikely to be optimized to unsigned int.  If they're
  88. ints, then you want to get unsigned int arithmetic, right?  One solution is
  89. to dictate that the expressions should be unsigned to begin with, and then
  90. you can omit all casts in your macros.  Your integral constants will have
  91. type int or unsigned int or long or unsigned long as necessary, and will be
  92. promoted to unsigned int or unsigned long as necessary for the operations.
  93. If you cannot dictate that way to your users, then you still need two versions,
  94. one with casts to unsigned int and one with casts to unsigned long.
  95.  
  96. >Would it be reasonable to omit all the #if tests, leaving just the part
  97. >that deals with longs of exactly 32 bits, and hope that the code never
  98. >runs on a system that has wider longs?
  99.  
  100. You don't have to hope; you could be SURE that the code will never run on
  101. a system that has wider longs.  Uh, I should say ALMOST sure, because the
  102. code might start out running for a while....  Anyway, you can restrict
  103. yourself to whatever market segment you like, but please publish your
  104. limitations before trying to sell your product.
  105. --
  106. Norman Diamond                diamond@jit.dec.com
  107. If this were the company's opinion, I wouldn't be allowed to post it.
  108. Pardon me?  Or do I have to commit a crime first?
  109.