definition of R_problem_buf in S.h (PR#210)
Kurt Hornik
Kurt.Hornik@ci.tuwien.ac.at
Tue, 15 Jun 1999 10:30:52 +0200 (CEST)
>>>>> Peter Dalgaard BSA writes:
> Guido Masarotto <guido@hal.stat.unipd.it> writes:
>> Allocating the buffer *inside* the function is easy if we insist
>> on the PROBLEM ....RECOVER interface (but K. has another opinion):
> Yes. I think Kurt is missing the point that S.h is a *compatibility*
> item, so we're stuck with whatever ugliness that is present in S. It
> is still allowed to do it neater.
Hmm. Is everyone trying to give me a hard time lately? I am aware that
it is there for compatibility. I was trying to say that even if we keep
the interface supported, we should still find a better way AND advertize
it accordingly.
>> #define PROBLEM {char R_problem_buf[R_PROBLEM_BUFSIZE];\
>> sprintf(R_problem_buf,
>> #define RECOVER(x) ), error(R_problem_buf); }
>>
>> Same for WARNING
>> Are there other use of the buffer?
> I don't think so...
> Let's see: This would create R_problem_buf on the stack when PROBLEM
> is encountered or when the function is called? (Forgetting my C
> semantics...). In either case, we certainly avoid the reentrancy
> problem. In the latter (unlikely) case, we waste 4k per potential
> PROBLEM, which is hardly a problem unless the function is heavily
> recursive. Sounds good.
In any case, let me get rid of this in appl/loglin.c. On a related
issue, what is the recommended way of allocating memory in such files,
via Calloc()?
-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._