tombre@crin.UUCP (Karl Tombre) (06/22/87)
A collegue showed me a strange problem today : calling one of her functions
in a very common way, she got strange results as the parameters seemed to
change between the call and the execution. Looking at this with dbx, we
found that a bogus parameter "c" was added somewhere. We checked the most
obvious explanation (some strange #defines) by running only the preprocessor
but this added no "c". We also isolated the code from the rest of the
program, and then nothing was added. So we don't see any valid reason. Is
this a bug of the cc compiler with Bsd 4.2 (on a Vax 11/785) ?
Here are some lines from a dbx run to illustrate the problem :
vax Cprog 52 %dbx sagat
dbx version of 11/2/83 16:31 (ucbmonet).
Type 'help' for help.
reading symbolic information ...
(dbx) list pos_ecrit
9 pos_ecrit(pf,nom,mode,d) <== this is the original code
10 FILE *pf;
11 char *nom,*mode;
12 long d;
13
(dbx) whatis pos_ecrit
int pos_ecrit(c, pf, nom, mode, d)
int c; <== where does this c come from ??
struct _iobuf *pf;
char *nom;
char *mode;
int d;
Thanks for all replies, in this newsgroups or by Email. If you reply by
Email, you can add zertal@crin.UUCP to the Destination field.
--
--- Karl Tombre @ CRIN (Centre de Recherche en Informatique de Nancy)
EMAIL : tombre@crin.UUCP
POST : Karl Tombre, CRIN, B.P. 239, 54506 VANDOEUVRE CEDEX, France
PHONE : +33 83.91.21.25kenm@sci.UUCP (Ken McElvain) (07/12/87)
In article <264@crin.UUCP>, tombre@crin.UUCP (Karl Tombre) writes:
- Here are some lines from a dbx run to illustrate the problem :
-
- vax Cprog 52 %dbx sagat
- dbx version of 11/2/83 16:31 (ucbmonet).
- Type 'help' for help.
- reading symbolic information ...
- (dbx) list pos_ecrit
-
- 9 pos_ecrit(pf,nom,mode,d) <== this is the original code
- 10 FILE *pf;
- 11 char *nom,*mode;
- 12 long d;
- 13
-
- (dbx) whatis pos_ecrit
-
- int pos_ecrit(c, pf, nom, mode, d)
- int c; <== where does this c come from ??
- struct _iobuf *pf;
- char *nom;
- char *mode;
- int d;
-
Probably somewhere above the function pos_ecrit there is a bad
extern function declaration looking something like
int foo(c);
The argument c of foo, which should't be there but is not checked for,
gets prepended onto the argument list for pos_ecrit. Since the type
is not specified it defaults to an int. I spent most of a day chasing
this down when it happened to me.
Ken McElvain
decwrl!sci!kenmtombre@crin.UUCP (Karl Tombre) (07/16/87)
In article <6988@sci.UUCP> kenm@sci.UUCP (Ken McElvain) writes: >Probably somewhere above the function pos_ecrit there is a bad >extern function declaration looking something like > >int foo(c); > >The argument c of foo, which should't be there but is not checked for, >gets prepended onto the argument list for pos_ecrit. Exactly ! That's what happened. Thanks to all who provided hints for finding this. But isn't it definitively a compiler bug, that the bad extern declaration isn't detected and leads to problems later ? -- --- Karl Tombre @ CRIN (Centre de Recherche en Informatique de Nancy) EMAIL : tombre@crin.UUCP POST : Karl Tombre, CRIN, B.P. 239, 54506 VANDOEUVRE CEDEX, France PHONE : +33 83.91.21.25
chris@mimsy.UUCP (Chris Torek) (07/17/87)
In article <292@crin.UUCP> tombre@crin.UUCP (Karl Tombre) writes: [something like extern int f(c); int foo(a, b) int a, b; { ... made the debugger think this was foo(c, a, b).] >But isn't it definitively a compiler bug ... ? Yes. `Fixed in 4.3.' (Donn Seeley caught this one, and a lot of others.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris