home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / gnu / gcc / help / 2734 < prev    next >
Encoding:
Text File  |  1992-12-13  |  2.1 KB  |  50 lines
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!Sirius.dfn.de!solaris.rz.tu-clausthal.de!urmel.informatik.rwth-aachen.de!tabaqui!dak
  2. From: dak@tabaqui.informatik.rwth-aachen.de (David Kastrup)
  3. Newsgroups: gnu.gcc.help
  4. Subject: Re: ?Strange behavior of char* vs. char[]
  5. Date: 13 Dec 92 15:46:39 GMT
  6. Organization: Rechnerbetrieb Informatik - RWTH Aachen
  7. Lines: 37
  8. Distribution: usa
  9. Message-ID: <dak.724261599@tabaqui>
  10. References: <MORGAN.92Dec10184806@dl5000.bc.edu>
  11. NNTP-Posting-Host: tabaqui.informatik.rwth-aachen.de
  12.  
  13. morgan@dl5000.bc.edu (Morgan Stair) writes:
  14.  
  15.  
  16. >When I compile the following (2 file) program all indications from gdb
  17. >are that everything should be fine, but without fail I get
  18. >segmentation faults.  I didn't want to post this to BUGS because
  19. >changing the "extern char *x" of sub.c to "extern char x[]" gets rid
  20. >of the errror, but I can't see why this happens.
  21.  
  22. >Any explanations???  This was done on a DECstation, but the results
  23. >are identical on the Sun, except that it seg-faults in _doprnt ()
  24. >instead of strlen ().
  25.  
  26.  
  27. >Here's the two files side by side:
  28. >    /*** main.c ***/                     |/*** sub.c ***/
  29. >    #include <stdio.h>                   |#include <stdio.h>
  30. >    extern void sub (void);              |extern char *x;
  31. >    char x[100];                         |char path[100];
  32.  
  33. >Like I said, I don't think this is a bug, since declaring x the same
  34. >way in both files makes it work right, but I thought arrays and
  35. >pointers were pretty much the same thing???
  36.  
  37. Not for the machine, only for the language. A pointer is something where
  38. you fetch the address to be used, an array something which you use directly
  39. as an address.
  40.  
  41. Things like that are the reason why declaring function, variables, in general
  42. anything shared between source modules should ALWAYS happen in include
  43. files so that the declarations match by necessity.
  44.  
  45. The amount of potential havoc caused by differing declarations increases
  46. with ANSI C (function call coercions) and is enormous with C++. But as you
  47. can see, even classic C is better of with common declarations in common
  48. files (by common I mean what the dictionary says, not those F***RAN
  49. fanatics).
  50.