search for: r_problem_buf

Full_Name: Thomas Vogels Version: 0.64.1 OS: AIX 4.2 Submission from: (NULL) (198.133.22.70) R_problem_buf is defined, not just declared, in S.h: #define R_PROBLEM_BUFSIZE 4096 char R_problem_buf[R_PROBLEM_BUFSIZE]; This is bad since every time S.h is included this buffer is defined. The linker will eventually complain about multiple definitions of this symbol. Solution: declare R_problem_buf to be...

Hi all, may I request the following two changes to Rdefines.h (R 0.65.1)? 1.) Change line 106 from #define Free(p) R_chk_free( (void *)(p) ) to #define Free(p) R_chk_free( (void *)(p) ) , p=NULL 2.) Add after line 79: #define PROBLEM {char R_problem_buf[R_PROBLEM_BUFSIZE];sprintf(R_problem_buf, a new line 80: #define PROBLEM {char R_problem_buf[R_PROBLEM_BUFSIZE];sprintf(R_problem_buf, #define MESSAGE {char R_problem_buf[R_PROBLEM_BUFSIZE];sprintf(R_problem_buf, The rationale behind both changes is to become more compatible with S.h from S-PLUS....

I didn't see any mention of this in the material on CRAN. The two S.h files define R_problem_buf as a real symbol rather than simply declaring its existence. As a result, a shared library that links two or more files that include this will get duplicate symbol complaints. Since it is not defined elsewhere in the code, someone has to define it. A secondly thing is the documentation for .C() an...

Duncan Temple Lang <duncan@rice.research.bell-labs.com> writes: > I didn't see any mention of this in the material on CRAN. The two S.h > files define R_problem_buf as a real symbol rather than simply > declaring its existence. As a result, a shared library that links two > or more files that include this will get duplicate symbol complaints. > Since it is not defined elsewhere in the code, someone has to define it. [I'll file this as a bug repor...

...missing definition for func Rf_initEmbeddedR which is prototyped as an extern in EmbeddedRCall.c Here are the issues again (in more detail) =========================================================== 1. Macro re-definition In file ..\include\R_ext\RS.h the line (37): #define ERROR ),error(R_problem_buf);} causes this problem : warning C4005: 'ERROR' : macro redefinition d:\visualstudio\vc98\include\wingdi.h(93) : see previous definition of 'ERROR' 2. Unresolved external: unresolved external symbol _Rf_initEmbeddedR This function is not defined anywhere. Does anyon...

...buffer sizes in printutils.c * PR# 135 * Subject: summary() of lm() problem From: Simon Fear <fears@roycastle.liv.ac.uk> Date: Tue, 9 Mar 1999 13:18:37 -0000 --lm (?) AND Windows problem; Win solved (fudged) for 0.63.3 -- --Another low-level buffer-size problem * PR# 185 * Subject: Re: [R] R_problem_buf in the S.h files & lists in .C From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> Date: 05 May 1999 00:32:49 +0200 --S objects in .C calls (not just lists) are now documented in the help file --Should we not make the buffer static? * PR# 197 * Subject: glm crash From: Cor en Aylin <Co...

...buffer sizes in printutils.c * PR# 135 * Subject: summary() of lm() problem From: Simon Fear <fears@roycastle.liv.ac.uk> Date: Tue, 9 Mar 1999 13:18:37 -0000 --lm (?) AND Windows problem; Win solved (fudged) for 0.63.3 -- --Another low-level buffer-size problem * PR# 185 * Subject: Re: [R] R_problem_buf in the S.h files & lists in .C From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> Date: 05 May 1999 00:32:49 +0200 --S objects in .C calls (not just lists) are now documented in the help file * PR# 197 * Subject: glm crash From: Cor en Aylin <Cor.Berrevoets@gironet.nl> Date: Fri, 2...

...buffer sizes in printutils.c * PR# 135 * Subject: summary() of lm() problem From: Simon Fear <fears@roycastle.liv.ac.uk> Date: Tue, 9 Mar 1999 13:18:37 -0000 --lm (?) AND Windows problem; Win solved (fudged) for 0.63.3 -- --Another low-level buffer-size problem * PR# 185 * Subject: Re: [R] R_problem_buf in the S.h files & lists in .C From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> Date: 05 May 1999 00:32:49 +0200 --S objects in .C calls (not just lists) are now documented in the help file * PR# 197 * Subject: glm crash From: Cor en Aylin <Cor.Berrevoets@gironet.nl> Date: Fri, 2...

...buffer sizes in printutils.c * PR# 135 * Subject: summary() of lm() problem From: Simon Fear <fears@roycastle.liv.ac.uk> Date: Tue, 9 Mar 1999 13:18:37 -0000 --lm (?) AND Windows problem; Win solved (fudged) for 0.63.3 -- --Another low-level buffer-size problem * PR# 185 * Subject: Re: [R] R_problem_buf in the S.h files & lists in .C From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> Date: 05 May 1999 00:32:49 +0200 --S objects in .C calls (not just lists) are now documented in the help file --Should we not make the buffer static? * PR# 197 * Subject: glm crash From: Cor en Aylin <Co...

...) AND Windows problem; Win solved (fudged) for 0.63.3 -- --Another low-level buffer-size problem * PR# 180 * Subject: nlm on a function in the Math group From: Douglas Bates <bates@stat.wisc.edu> Date: Thu, 29 Apr 1999 17:11:00 -0500 (CDT) --causes R to core dump * PR# 185 * Subject: Re: [R] R_problem_buf in the S.h files & lists in .C From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> Date: 05 May 1999 00:32:49 +0200 --S objects in .C calls (not just lists) are now documented in the help file Directory: Misc * PR# 91 * Subject: possible bug From: Rashid Nassar <rnassar@duke.edu>...

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or