home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18273 < prev    next >
Encoding:
Text File  |  1992-12-12  |  3.2 KB  |  86 lines
  1. Path: sparky!uunet!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
  2. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Question to test general C knowledge
  5. Message-ID: <1992Dec12.230520.771@thunder.mcrcim.mcgill.edu>
  6. Date: 12 Dec 92 23:05:20 GMT
  7. References: <Bz0A46.Cvu@watserv1.uwaterloo.ca> <19980@ksr.com> <1992Dec11.180939.20726@crd.ge.com>
  8. Organization: McGill Research Centre for Intelligent Machines
  9. Lines: 76
  10.  
  11. In article <1992Dec11.180939.20726@crd.ge.com>, volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:
  12. > In article <1992Dec11.091819.26636@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  13. >> In article <19980@ksr.com>, jfw@ksr.com (John F. Woods) writes:
  14.  
  15. >>>     int i = 2;
  16. >>>     i = ++i;
  17. >> "Anything or nothing.  3 seems most probable, with 4 next."
  18. >                                                ^^^^^^^^^^^^
  19. > Why?
  20.  
  21. Based on a sequence like
  22.  
  23.         ! compute needed values
  24.         addl3   _i,$1,r0        ! compute value of ++i
  25.         ! sequence point; do accumulated side-effects
  26.         movl    r0,_i           ! store value of ++i into i
  27.         incl    _i              ! increment i
  28.  
  29. Thus we see the wisdom of ANSI's rule :-)
  30.  
  31. > The effect of the "++" is to assign 3 to i.
  32.  
  33. The effect of the ++ is to increment i.  Whether this results in
  34. assigning 3 to it depends on whether it still has the value 2 when the
  35. increment gets around to happening.
  36.  
  37. > (Other than, of course, a vindictive compiler that detected
  38. > violations of the letter of the law and went out of its way to give
  39. > you garbage.)
  40.  
  41. I have often wished that compilers had a flag that said "please be as
  42. perverse as you can and break as many invalid assumptions as you can",
  43. as an aid to bug-finding.  gcc with loads of warnings turned on is
  44. fairly good at finding invalid code, but there are some things that it
  45. by its nature can't do.  For example,
  46.  
  47. double sqrt(double);
  48. int isqrt(int);
  49.  
  50. struct {
  51.   char *name;
  52.   int type;
  53. #define T_D_D 1 /* double xxx(double) */
  54. #define T_I_I 2 /* int xxx(int) */
  55.   void (*fn)(void);
  56.   } optable[] = { { "sqrt", T_D_D, (void (*)(void)) sqrt },
  57.                   { "isqrt", T_I_I, (void (*)(void)) isqrt },
  58. ....
  59.                   { 0 } };
  60. ....
  61.  for (i=0;optable[i].name;i++)
  62.   { if (!strcmp(optable[i].name,opname))
  63.      { switch (optable[i].type)
  64.         { case T_D_D:
  65.              push_result( TYPE_DOUBLE,
  66.                           (*(double (*)(double))optable[i].fn)
  67.                                 (*(double *)pop_value()) );
  68.              break;
  69.           case T_I_I:
  70.              push_result( TYPE_INTEGER,
  71.                           (*(double (*)(double))optable[i].fn)
  72.                                 (*(double *)pop_value()) );
  73.              break;
  74. ....
  75.  
  76. Now, the T_I_I case is broken: the casts should be (int (*)(int)) and
  77. (int *).  But the compiler is required to accept the code anyway; it
  78. takes run-time checking to catch this.  (This is not real code, but
  79. very similar code is likely to exist in interpreters of some sorts.)
  80. Nonetheless, on some systems, it may work anyway because doubles are
  81. passed and returned in ways similar to those use for ints....
  82.  
  83.                     der Mouse
  84.  
  85.                 mouse@larry.mcrcim.mcgill.edu
  86.