Menu

#3 Inconsistent arguments/parameters with forward declarations

1.0
closed
0.4 (3)
2017-12-16
2017-11-27
No

Please note that this problem is relevant only to 32-bit mode.

(I'm just going to describe the problem here as producing an executable
test case would involve lots of setup. If my point is not clear, I could
try to do something about creating such a test case.)

Consider a scenario in which I am attempting to fill a read buffer, but
my read call can return prematurely. (The POSIX read call works with way
for "slow" devices.) I must loop over the read call, and I must decide
a buffer strategy. One way would be to do each read into a temporary
buffer and then catenate that buffer to the end of the regular buffer.
Another is to use pointer arithmetic to get the read call to use
the appropriate subsection of the regular buffer.

Consider the following program fragment, which using pointer arithmetic
on a buffer (unimportant declarations and statements omitted):
xread: procedure (..., buf, nbytes);
declare buf character;
declare nbytes fixed;
...
end xread;
readfull: procedure (...);
declare buff (99);
declare pos fixed initial (0);
do ...;
nread = xread (..., addr (buff) + pos, 100 - pos);
pos = pos + nread;
end;
end readfull;

The call to xread is translated into something like the following:
int xread (..., char *buff, int nbytes);
char buff [100];
nread = xread (..., (intmax_t) addr (buff) + pos,
100 - (intmax_t) pos);

Note that in a 32-bit program the argument and parameter lists do not
match. The argument list has 64-bit variables, but the parameter list
has 32-bit variables. However, the C compiler notices the discrepancy
(because there is an preceding declaration of xread) and reduces the
width of the parameters. Something like:
nread = xread (..., (char *) ((intmax_t) addr (buff) + pos),
(int) (100 - (intmax_t) pos));
So, everything works.

Now consider the same program, but in a different order:
declare xread label;
readfull: procedure (...);
...
end readfull;
xread: procedure (..., buf, nbytes);
...
end xread;
Now there is no declaration of xread in scope, and (as in K&R C) the C
compiler does not narrow the variables in the call. This means that
the call to xread is garbled -- the variables in the parameter list do
not correspond to those in the argument list.

Again, note that this is due to my use of 32-bit mode.

Perhaps one way to alleviating this problem (while still maintaining the
"one-pass" aspect) would be to write a declaration into the ".xh" file
for each definition written into the ".c" file.

Discussion

  • Daniel Weaver

    Daniel Weaver - 2017-11-30
    • assigned_to: Daniel Weaver
     
  • Daniel Weaver

    Daniel Weaver - 2017-12-16

    Fixed in 0.4. Use the EXTERNAL keyword to define a function prototype.

     
  • Daniel Weaver

    Daniel Weaver - 2017-12-16
    • labels: --> 0.4
    • status: open --> closed
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.