home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / sys5 / r3 / 185 < prev    next >
Encoding:
Text File  |  1993-01-09  |  2.9 KB  |  97 lines
  1. Xref: sparky comp.unix.sys5.r3:185 comp.unix.programmer:5873 biz.sco.general:5041
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!bazooka!ti
  3. From: ti@bazooka.amb.org (Ti Kan)
  4. Newsgroups: comp.unix.sys5.r3,comp.unix.programmer,biz.sco.general
  5. Subject: Compiler wierdness alert...
  6. Message-ID: <1252@bazooka.amb.org>
  7. Date: 9 Jan 93 20:15:31 GMT
  8. Reply-To: ti@bazooka.amb.org (Ti Kan)
  9. Followup-To: comp.unix.sys5.r3
  10. Organization: AMB Research Labs, Sunnyvale, CA.
  11. Lines: 84
  12.  
  13.  
  14. Consider the following program:
  15.  
  16. ----------------------------------
  17. #include <stdio.h>
  18.  
  19. #pragma pack(1)
  20. union foo {
  21.     char d1;
  22.     long d2;
  23. };
  24. #pragma pack()
  25.  
  26. struct bar {
  27.     char a;
  28.     char b;
  29.     char c;
  30.     union foo d;
  31. };
  32.  
  33. main()
  34. {
  35.     struct bar x;
  36.  
  37.     /* display the relative offsets of struct bar members */
  38.     printf("\t%d %d %d %d\n",
  39.         (char *) &x.a - (char *) &x,
  40.         (char *) &x.b - (char *) &x,
  41.         (char *) &x.c - (char *) &x,
  42.         (char *) &x.d - (char *) &x);
  43. }
  44. ----------------------------------
  45.  
  46. Program output (Compiled with cc on 3.2v2 DS or or gcc 2.2.2):
  47.  
  48.     0 1 2 4
  49.  
  50. Program output (Compiled with cc 3.2v4 DS, or rcc on both 3.2v2 DS
  51. and 3.2v4 DS):
  52.  
  53.     0 1 2 3
  54.  
  55. So, with cc on 3.2v4 or rcc in both versions, the compiler does not put
  56. a pad byte after field "c" in struct bar, whereas with cc on
  57. 3.2v2 DS or gcc, it does.
  58.  
  59. What significance is there?  Well, for most applications writers
  60. there isn't a problem, as long as all modules that use this structure
  61. are compiled with the same compiler.  There will be a problem if you
  62. are going to be mixing object files or libraries compiled with different
  63. compilers.
  64.  
  65. For device driver writers, there is definitely a problem.  If there
  66. is a kernel structure defined as such, and the kernel was compiled with
  67. a different compiler than yours, then there is a serious bug.
  68.  
  69. Guess what, there is exactly such a case.  In /usr/include/sys/scsi.h,
  70. on both SCO 3.2v2 and 3.2v4, there is a "scsi_io_req" structure which
  71. contains a subfield "union scsi_cdb".  The starting offset of this
  72. union varies depending upon which compiler you use.
  73.  
  74. It appears that the SCO 3.2v4 kernel is compiled with the 3.2v2
  75. Dev Sys compiler, so if you compile a SCSI device driver using the
  76. 3.2v4 DS compiler, you're in for a nice surprise.
  77.  
  78. Of course there is a workaround, just by explicitly inserting a
  79. pad byte into the structure before the scsi_cdb union will solve this
  80. particular case.  But how many other similar situations are there?
  81.  
  82. I don't know if there is an ANSI standard or somesuch that dictates
  83. the correct compiler behavior in this scenario, but SCO has definitely
  84. introduced an incompatibility between the cc compiler between 3.2v2 DS
  85. and 3.2v4 DS.
  86.  
  87. Just thought I'd make everyone aware of this... I found out the hard
  88. way.
  89.  
  90. -Ti
  91. -- 
  92.     ///  Ti Kan                vorsprung durch technik
  93.    ///   AMB Research Laboratories, Sunnyvale, CA. USA
  94.   ///    ti@amb.org
  95.  //////  ...!{decwrl,synopsys,tandem,tsoft,ultra}!sgiblab!bazooka!ti
  96. ///      ...!{uunet,sun,apple,sco}!altos!bazooka!ti
  97.