home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 6622 < prev    next >
Encoding:
Text File  |  1992-07-24  |  2.8 KB  |  137 lines
  1. Path: sparky!uunet!zephyr.ens.tek.com!uw-beaver!news.u.washington.edu!milton.u.washington.edu!kenney
  2. From: kenney@milton.u.washington.edu (Michael Kenney)
  3. Newsgroups: comp.os.linux
  4. Subject: Strange gcc problem/bug
  5. Message-ID: <1992Jul24.145038.29755@u.washington.edu>
  6. Date: 24 Jul 92 14:50:38 GMT
  7. Sender: news@u.washington.edu (USENET News System)
  8. Reply-To: kenney@u.washington.edu
  9. Organization: University of Washington, Seattle
  10. Lines: 125
  11.  
  12.  
  13. Fellow Linux users,
  14.  
  15. I think I have run across a bug in gcc v2.2.2.
  16.  
  17. Consider the following bit of code (the getuname function is from the
  18. getty_ps package):
  19.  
  20. ---------------------------------------
  21. #include <stdio.h>
  22. #include <stdlib.h>
  23. #include <unistd.h>
  24. #include <sys/param.h>
  25. /*
  26. **    getuname() - retrieve the system's node name
  27. **
  28. **    Returns pointer to name or a zero-length string if not found.
  29. */
  30. char *
  31. getuname()
  32. {
  33.     struct utsname uts;
  34.     static char name[80];
  35.     int r;
  36.     name[0] = '\0';
  37.     if (uname(&uts) != -1)
  38.         (void) strcpy(name, uts.nodename);
  39.     return(name);
  40. }
  41.  
  42. main(ac, av)
  43. unsigned    ac;
  44. char        **av;
  45. {
  46.     printf("hostname = %s\n",getuname());
  47. }
  48. -------------------------------------------------------------------------
  49.  
  50. When I compile the above program, I get the following output:
  51.  
  52.     /lib/libc2.2.2
  53.  
  54. If I use static linking, I get no output at all.  What really makes things
  55. interesting is; if I make "uts" static in getuname, everything works fine.
  56.  
  57. Here's the assembler output for getuname (uts local):
  58.  
  59. --------------------------------------------------------------------------
  60.     .file    "testname.c"
  61. gcc2_compiled.:
  62. .lcomm _name.6,80
  63. .text
  64.     .align 2
  65. .globl _getuname
  66. _getuname:
  67.     pushl %ebp
  68.     movl %esp,%ebp
  69.     subl $276,%esp
  70.     movb $0,_name.6
  71.     leal -272(%ebp),%eax
  72.     pushl %eax
  73.     call _uname
  74.     addl $4,%esp
  75.     movl %eax,%eax
  76.     cmpl $-1,%eax
  77.     je L7
  78.     leal -207(%ebp),%eax
  79.     pushl %eax
  80.     pushl $_name.6
  81.     call _strcpy
  82.     addl $8,%esp
  83. L7:
  84.     movl $_name.6,%eax
  85.     jmp L6
  86.     .align 2,0x90
  87. L6:
  88.     leave
  89.     ret
  90. ---------------------------------------------------------------------------
  91.  
  92. Now here's the case for static uts:
  93.  
  94. ----------------------------------------------------------------------------
  95.     .file    "testname.c"
  96. gcc2_compiled.:
  97. .lcomm _uts.6,272
  98. .lcomm _name.7,80
  99. .text
  100.     .align 2
  101. .globl _getuname
  102. _getuname:
  103.     pushl %ebp
  104.     movl %esp,%ebp
  105.     subl $4,%esp
  106.     movb $0,_name.7
  107.     pushl $_uts.6
  108.     call _uname
  109.     addl $4,%esp
  110.     movl %eax,%eax
  111.     cmpl $-1,%eax
  112.     je L7
  113.     pushl $_uts.6+65
  114.     pushl $_name.7
  115.     call _strcpy
  116.     addl $8,%esp
  117. L7:
  118.     movl $_name.7,%eax
  119.     jmp L6
  120.     .align 2,0x90
  121. L6:
  122.     leave
  123.     ret
  124. ----------------------------------------------------------------------------
  125.  
  126. Anybody know what's going on here?  I'm not that familiar with Minix
  127. assembler, does "leave" clean up the stack properly before returning?
  128. I was slogging through this fairly late last night so there may be something
  129. obvious that I am missing :-).
  130.  
  131. Mike
  132.  
  133. ----------
  134. Mike Kenney
  135. UW Applied Physics Lab
  136. mikek@apl.washington.edu
  137.