🚀 go-pugleaf

morgan@dl5000.bc.edu (Morgan Stair) writes:


>When I compile the following (2 file) program all indications from gdb
>are that everything should be fine, but without fail I get
>segmentation faults.  I didn't want to post this to BUGS because
>changing the "extern char *x" of sub.c to "extern char x[]" gets rid
>of the errror, but I can't see why this happens.

>Any explanations???  This was done on a DECstation, but the results
>are identical on the Sun, except that it seg-faults in _doprnt ()
>instead of strlen ().


>Here's the two files side by side:
>    /*** main.c ***/                     |/*** sub.c ***/
>    #include <stdio.h>                   |#include <stdio.h>
>    extern void sub (void);              |extern char *x;
>    char x[100];                         |char path[100];

>Like I said, I don't think this is a bug, since declaring x the same
>way in both files makes it work right, but I thought arrays and
>pointers were pretty much the same thing???

Not for the machine, only for the language. A pointer is something where
you fetch the address to be used, an array something which you use directly
as an address.

Things like that are the reason why declaring function, variables, in general
anything shared between source modules should ALWAYS happen in include
files so that the declarations match by necessity.

The amount of potential havoc caused by differing declarations increases
with ANSI C (function call coercions) and is enormous with C++. But as you
can see, even classic C is better of with common declarations in common
files (by common I mean what the dictionary says, not those F***RAN
fanatics).