Backtrace function

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

Is that what this is all about?

If you don't know what it's all about, why are you participating in the
thread? comp.lang.c is not a write-only newsgroup.

 

[CBFalconer]

CBFalconer said:

If you don't know what it's all about, why are you participating
in the thread? comp.lang.c is not a write-only newsgroup.

I have done you the favor of correcting your quote above. Your
newsreader seems to have problems providing a complete and readable
quote.

 

[Kelsey Bjarnason]

CBFalconer said:


Please cite the section of the Standard that requires the source code of
a called function to be present at compilation.



So if it were accompanied by int y(void) { return 124; } that would
*not* be standard C? What are the criteria?

A given program may or may not be standard C, but if the program uses
anything beyond the standard library - its own functions, other library
functions, what have you - the only way to determine whether it qualifies
as standard C is to examine the code.

Take the example:

x = y();

Is this standard C? Depends. Perhaps y() draws a line graph by directly
accessing the VGA hardware on a DOS machine, then returns a far pointer
to the video memory. I suspect there's no way to do this in standard C,
so to determine whether x = y(); is standard C requires examining what y
does.

The syntax may be standard C; is that sufficient to determine that the
program is, without seeing the whole program, including any additional
libraries or other modules?

 

[jacob navia]

A given program may or may not be standard C, but if the program uses
anything beyond the standard library - its own functions, other library
functions, what have you - the only way to determine whether it qualifies
as standard C is to examine the code.

Take the example:

x = y();

Is this standard C? Depends. Perhaps y() draws a line graph by directly
accessing the VGA hardware on a DOS machine, then returns a far pointer
to the video memory. I suspect there's no way to do this in standard C,
so to determine whether x = y(); is standard C requires examining what y
does.

The syntax may be standard C; is that sufficient to determine that the
program is, without seeing the whole program, including any additional
libraries or other modules?

By this logic the function printf is NOT standard C since
it must access stdout and put characters in it. To do this,
eventually a device driver must be called that will access the screen or
the disk or what ever output medium is concerned. This device driver
will be surely be written in some other language than standard C.

Q.E.D

To be *useful* all implementations must eventually call non-standard
functions to do input/output.

 

[Richard Heathfield]

CBFalconer said:

I have done you the favor of correcting your quote above. Your
newsreader seems to have problems providing a complete and readable
quote.

No, my newsreader works just fine, and I quoted the part I thought
relevant. If anyone (such as yourself) feels that the quoted part is
insufficient, they can check the rest of the feed or the archives.

Having said that, the "amplified" version that you have provided does not
change the point that I have made. (Had it done so, you would have had a
case for selective quotation. As it is, all you seem to be doing is
attempting to evade the point.)

 

[CBFalconer]

Kelsey Bjarnason wrote:
.... snip ...


By this logic the function printf is NOT standard C since it must
access stdout and put characters in it. To do this, eventually a
device driver must be called that will access the screen or the
disk or what ever output medium is concerned. This device driver
will be surely be written in some other language than standard C.

To the contrary, printf action is precisely defined in the C
standard. No unexpected action will occur, barring misuse.
However, you will have a hard time finding a description of y() in
the standard.

 

[Dik T. Winter]

> Flash Gordon wrote: ....
>
> The function address is always saved, or, sometimes held in a
> designated register. In both cases it is at a fixed point.

The return address is *not* always saved in RAM. Think about processors
with register windows where the last n (for some small value of n)
register sets are not yet saved in RAM but still reside in register
windows. Of course, on such a system there might be an instruction that
flushes the register windows (on the SPARC there is one: TRAP 3).