Hi, first off: Some more words on the naming issue. I actually still prefer the most simple and straightforward variant (i.e. BACKTRACE, which can easily be found and does not sound 'clumsy') ...
>>>> Or, why not just (plain and simple) "BACKTRACE"? >>> >>> The name is the same as backtrace() in glibc, but otherwise, sure why >>> not. Is that actually an issue at all? The intrinsic procedure would be accessible as BACKTRACE from Fortran programs, but internally it receives the usual libgfortran name mangling, which makes it _gfortran_backtrace. So there should be no naming collision issues with glibc's backtrace(), right? >>> _show/_print might be preferable in the sense that they convey >>> that stuff will be directly printed on the screen, rather than, say, >>> the procedure returning an array of strings with the stack trace info. I don't see that as a problem either, since we probably do not want to add another intrinsic which returns the backtrace as a string or something (if anything, we might add an optional integer argument, in order to print to a different unit, but I'm not proposing to do that right now). In any case, the procedure's behavior is described in the documentation. >> Do you have any further comments or do you think the patch is ok for trunk >> now? > > Ok for trunk. A minor addition, if you care, would be to mention in > the documentation for backtrace_show() that the error message is > printed to the unit corresponding to ERROR_UNIT in ISO_FORTRAN_ENV. Done. > Thanks for the patch! Thanks for reviewing. Attached is a new patch, which expands the documentation according to your proposal, and uses the name BACKTRACE. I hope that both Janne and Tobias can agree with this naming decision ... Cheers, Janus
pr36044_v3.diff
Description: Binary data
