#prototype question
11 messages in this thread
I've got a medium-sized c project — several .c and .h files — and have
noticed something very puzzling while debugging: it seems like the compiler
is forgetting some of my function prototypes! Example:
foo.h:
double find_z( SURFACE *s, PAIR p );
/* "SURFACE" is a typedef'ed struct;
"PAIR" is typedef for an array of 2 doubles */
bar.c:
double tz;
SURFACE surf;
PAIR xy;
/* a whole bunch of code…*/
tz = find_z( surf, xy );
When I compile bar.c using the list option to see how things are defined,
it says
…foo: external function returning int….
I'm compiling with the ansi & strict options on, and just to make sure,
I commented out the prototype in foo.h & got the appropriate error message.
I just recently upgraded to SAS/C 6.0, and it seems to be working ok (other
than this)….
What am I doing????
Thanks in advance for any suggestions….
… Whapped from
Jeff P.
Jeff-
PMFJI, but if your code does *exactly* what you list, you're passing a
SURFACE object to a routine expecting a pointer to same.
We now return you to your regularly scheduled programming…
Bob
– (!) –
Bob,
Hmmm — that was a typo in my message. The parameters in the program are
ok. What's weird about this situation is that there's another routine,
with the same parameters, called the same way, about 5 lines above, that
works just fine. When I run it thru the debugger, I see things like:
SURFACE *sp;
PAIR xy;
VECTOR nv
sp = < allocate & initialize memory for a SURFACE struct >
z = find_zn( sp, xy, nv );
< d sp —> 0x326B20 ….>
< ts >
double find_zn( SURFACE *bs, PAIR p, VECTOR v )
{
<some local variable declarations>
if(bs->surface_type == SPHERE)
{ ….
< d bs —> 0x3177DA…. >
Also, the cross-reference listing and the debugger both seem to think that
find_zn ( and other routines too ) return int's — but their prototypes
declare them as returning doubles — and I'm compiling with ANSI & STRICT
settings so I'd be getting compile errors if the proto's weren't there….
Thanks for taking a look, though… (your comment made me double-check my
.h files, which never hurts…)
… Whapped from
Jeff P.
It looks like you're writing a 3D-oriented program. What does it do?
I'm writing software to analyze eyeglass prescriptions prior to
fabrication. Lots of geometrical optics, plus some occasionally challenging
math to model the various aspheric and/or progressive-power lens designs.
… Whapped from
Jeff P.
Hmmm… I just typed in basically the same program you just typed in
and got the right answer with NOMATH and each of the MATH options.
Can you post or send me a compilable example that illustrates the
problem? Include the options used, including the SCOPTIONS file,
and any source code. It might be easier to use the PPONLY option
to generated preprocessed output, then just upload that file.
(Actually, sometimes the preprocessed output itself has clues as
to what is going on.)
One other thing to try: pass the result of the function to a
function that takes "char *", and see what type the error message
prints out. If it says "expecting char *, found double" then
at least the compiler knows what is going on, and it's a cross-
reference bug. If it says something else, then something non-
obvious is happening. You're not #defining 'double' to 'int'
or anything like that, are you <g>?
–Doug
Doug,
Thanks for the reply. It seems like I may have found my problem, or at
least part of it — I changed the data & code options to FAR & FAR & it
started working, sort of. Actually the functions were working ok, just
seems like the cross-reference list and "whatis" in cpr were wrong.
Interstingly enough, now what happens is that the pointers are valid when
I look at then IN the functions, but BEFORE the function call if I look at
the struct pointers with cpr, it says they're null, which is obviously not
correct….
If you don't mind, I'm seeing a new and (of course) worse problem
today:
I broke up several modules that had contained several functions each
in order to use the "gen_protos" option. That worked ok (I think) — got
a whole bunch of _proto.h files & they seem to be correct — then I built
a link-library & tried to use it. No actual code changes, just excerpted
stuff… Anyway I'm getting link error # 509: Unknown hunk type 867 in
pass 2. The book says to let you guys know if I get that one, so….
What now?
I'd be glad to upload an example of the previous problem if you want…
This one will be more difficult because there are 60+ modules involved.
I have Library listing & cross-ref (from oml) and also dumpobj output for
my library — if you can suggest anything to look for or try I'd be most
appreciative.
Hmmm…. This is turning fairly confusing for me, I think I have lost
track of what the problem is. DATA=FAR and CODE=FAR shouldn't affect
whether the prototypes are found at all, although it will affect
the listing. An example would be very helpful – this may well be
a debugging information problem that should be fixed.
Have you contacted technical support with this problem? They will
work with you to get a test case, if necessary, and they can track
the problem and make sure it doesn't get lost. (I'm here on a
personal account at home, so I don't have access to the bug
tracking system.)
The link error sounds like a bad object file. Try deleting all your
.o files and recompiling. Did you get any messages while compiling?
–Doug
Doug,
Well, I did contact tech support, & they thought maybe one particular
object module might be causing the problem, so I started breaking my
library in halves, in hopes of isolating one module eventually. The
original library was a little over 300k in size. When I got the parts
down to < 150k, it worked fine…. no changes to c code or options or
anything.
The original weirdness with codeprobe is still around, and I do have a
small test program which shows the situation…. Don't know when I'll get
a chance to send it off to SAS; my current priorities are to get more
functions working & this is more of a puzzle than a roadblock.
One other "interesting" thing: before I was using oml, I had about a
half dozen .o files which were included in the link command… I broke the
sources up into individual files ( one function per source file instead of
several ), and built my libraries from the resulting 50+ .o files. Now
when I link, the resulting executable has grown from originally a little
over 300 k to over 600 k. I had expected no change or slightly smaller,
since there were a couple of functions in the original big object modules
which weren't yet used. Does the linker allign modules in some way that
would cause this? ( many of my new modules are quite small, only a line or
to of c code in several cases. )
Thanks for the help.
It sounds to me like you are using a debug option higher than
DEBUG=LINE, which would cause debugging information to be
linked in. If you have one 1000-line file that #includes
stdio.h, all the structures defined therein are included
in the debug information; if you have 10 100-line files,
all that information is included ten times, resulting
in a larger executable.
Try linking with the NODEBUG linker option (STRIPDEBUG if
you link with the SC command) and I'll wager that the
size will be much closer.
–Doug
Doug,
That sounds reasonable… I've been using FullSymbol/Flush debugging
option — but was also using that before, so I couldn't understand why
things would suddenly get bigger, but if in fact there's debug info
generated by #including stdio & etc, then it makes sense.
(auto-piloted from)
JcP