Re: [Rd] Bug in the package RODBC (PR#13745)
On Jun 5, 2009, at 9:30 AM, nachiket...@cox.net wrote:
> Full_Name: N. Srinivasan
> Version: 2.8.1
> OS: Linux
> Submission from: (NULL) (68.110.225.2)
>
>
> * Installing *source* package 'RODBC' ...
> checking for gcc... gcc -std=gnu99
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc -std=gnu99 accepts -g... yes
> checking for gcc -std=gnu99 option to accept ANSI C... none needed
> checking how to run the C preprocessor... gcc -std=gnu99 -E
> checking for egrep... grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking sql.h usability... no
> checking sql.h presence... no
> checking for sql.h... no
> checking sqlext.h usability... no
> checking sqlext.h presence... no
> checking for sqlext.h... no
> configure: error: "ODBC headers sql.h and sqlext.h not found"
> ERROR: configuration failed for package 'RODBC'
> ** Removing '/home/user1/R-2.8.1/library/RODBC'
>
> The downloaded packages are in
> /tmp/RtmpmB0FH5/downloaded_packages
> Updating HTML index of packages in '.Library'
> Warning message:
> In install.packages("RODBC") :
> installation of package 'RODBC' had non-zero exit status
That's not a bug.
You are missing the required header files as noted in the error message.
You need to have unixODBC AND the unixODBC development package
installed as well. The latter has the header files.
You do not indicate what Linux distribution you are using, so we are
going to be limited in providing additional details for resolution.
A search of the R-Help archives would have told you the above as it
has come up frequently before. It would have saved you time and would
have saved a member of R Core from having to manually process a bug
report that was filed in error. Next time, please search the archives
or post a message to R-Help if you are unsure.
HTH,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ordering dataframe for strata() (PR#13830)
On Jul 14, 2009, at 2:10 PM, eric.vander...@usask.ca wrote:
> I've been using strata(sampling) and found that if the dataframe to be
> sampled ("data") consists of repeated measures that are not sorted in
> order the run will fail on a given stratum. Ordering the dataframe
> prior to using strata() eliminates this problem.
>
> Thanks,
> Eric
If you are reporting a bug, then as per the R FAQ and the Posting
Guide, you are asked to report bugs on contributed packages to the
package maintainer, not to the R Bug Repository.
If you are simply reporting curious behavior for the benefit of
others, then please post it to R-help and do not report it as a bug. I
would still contact the package maintainer, who may wish to add
clarifications to the package/function documentation.
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table() can't read in this table (But Splus can) (PR#9687)
On Mon, 2007-05-14 at 23:41 +0200, [EMAIL PROTECTED] wrote:
> Full_Name: vax, 9000
> Version: 2.4.0, 2.2.1
> OS: 2.4.0: Mac OS X; 2.2.1: Linux
> Submission from: (NULL) (192.35.79.70)
>
>
> To reproduce this bug, first go to the website "http://llmpp.nih.gov/DLBCL/";
> and
> download the 14.8M data set "Web Figure 1 Data file". The direct link is
> "http://llmpp.nih.gov/DLBCL/NEJM_Web_Fig1data";. Save it as "datafile.txt"
>
> Then, start R, type in command "x <- read.table("datafile.txt", header=TRUE,
> sep="\t")". The data has 7400 lines, but not all lines could be read in by R.
>
> Easier test data set:
> Use the command "head -n 100 datafile.txt > shortdatafile.txt" to extract the
> first 100 lines. The R command "x <- read.table("datafile.txt", header=TRUE,
> sep="\t")" could not read in even this 100 lines of data.
>
> But Splus can, with the same command. What is wrong?
Using R version 2.5.0 Patched:
> DF <- read.table("http://llmpp.nih.gov/DLBCL/NEJM_Web_Fig1data";, header =
> TRUE, sep = "\t")
Warning message:
number of items read is not a multiple of the number of columns
So I tried it with 'fill = TRUE' and that seems to work, which suggests
that perhaps something is going on with the data file structure:
DF <- read.table("http://llmpp.nih.gov/DLBCL/NEJM_Web_Fig1data";,
header = TRUE, sep = "\t", fill = TRUE)
> str(DF)
'data.frame': 4734 obs. of 295 variables:
$ UNIQID : int 27481 17013 24751 27498
27486 30984 17293 28329 27459 27482 ...
$ NAME : Factor w/ 4040 levels
"||*AA037178|Hs.179661|FK506 binding protein 1A (12kD)",..: 3444 3445 3446 3444
3445 657 1788 3121 3119 3119 ...
$ MLC94.46_LYM009_de.novo.untreated : num 0.234 0.452 0.405 0.115
0.249 ...
$ MLC96.45_LYM186_de.novo.untreated : num -0.1725 -0.0387 -0.0413
-0.0242 -0.1028 ...
$ MLC91.27_LYM427_de.novo.untreated : num 0.200 0.175 0.195 0.223
0.179 ...
$ MLC96.84_LYM225_transformed: num -0.213 -0.325 -0.200
-0.199 -0.155 ...
$ MLC95.43_LYM095_de.novo.untreated : num -0.1197 0.0038 -0.0213
-0.0705 -0.0755 ...
$ MLC91.28_LYM428_de.novo.untreated : num -0.3729 0.0047 -0.2220
-0.3373 -0.2808 ...
$ MLC94.50_LYM004_de.novo.untreated : num -0.195 -0.224 -0.126
-0.161 -0.199 ...
$ MLC95.46_LYM098_de.novo.untreated : num 0.489 0.611 0.577 0.661
0.519 ...
$ MLC95.62_LYM114_de.novo.untreated : num 0.390 0.657 0.747 0.723
0.731 ...
$ MLC95.85_LYM137_de.novo.untreated : num -0.277 -0.564 -0.297
-0.140 -0.513 ...
..
I would update your version of R and then re-try this.
HTH,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot() confuses x- and y-axes (PR#10345)
On Mon, 2007-10-15 at 10:30 +0200, [EMAIL PROTECTED] wrote: > Full_Name: Bob O'Hara > Version: 2.6.0 > OS: Windows XP > Submission from: (NULL) (88.112.20.250) > > > Using horizontal=TRUE with boxplot() confuses it as to what is an x- or > y-axis. > At least, xlim= and ylim= are the wrong way round, log="x" (or "y") and xaxt= > work as expected, I haven't looked at anything else. > > Some code to see if you can reproduce the bug (or discover it's in my > head...): > > boxplot(count ~ spray, data = InsectSprays) > > # Try to change x-axis: > boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50)) > > # Plot horizontally: > boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE) > > # Now try to change x-axis: > boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xlim=c(0,50)) > # Changes y-axis! > > # Now try to change y-axis: > boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, ylim=c(0,50)) > # Changes x-axis! > > # Plot x-axis on log scale: > boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE, log="x") > # Does indeed change x-axis > > # Don't add ticks on x-axis: > boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xaxt="n") > # Works as expected. Hi Bob, No, it's not in your head. This is documented in ?bxp, which is the function that actually does the plotting for boxplot(). See the description of 'pars' in ?bxp: "Currently, yaxs and ylim are used âalong the boxplotâ, i.e., vertically, when horizontal is false, and xlim horizontally." So essentially, the named 'x' and 'y' axes are rotated 90 degrees when you use 'horizontal = TRUE', rather than the vertical axis always being 'y' and the horizontal axis always being 'x'. This has been discussed on the lists previously. Regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot() confuses x- and y-axes (PR#10345)
--=-ZyOtZFb05MaZLi4/Ovwu
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Mon, 2007-10-15 at 18:25 +0200, [EMAIL PROTECTED] wrote:
> > "JO" == Jari Oksanen <[EMAIL PROTECTED]>
> > on Mon, 15 Oct 2007 16:42:24 +0300 writes:
>
> JO> On Mon, 2007-10-15 at 15:25 +0200, [EMAIL PROTECTED] wrote:
> >> > "ms" == marc schwartz <[EMAIL PROTECTED]>
> >> > on Mon, 15 Oct 2007 14:20:16 +0200 (CEST) writes:
> >>
> ms> On Mon, 2007-10-15 at 10:30 +0200, [EMAIL PROTECTED] wrote:
> >> >> Full_Name: Bob O'Hara
> >> >> Version: 2.6.0
> >> >> OS: Windows XP
> >> >> Submission from: (NULL) (88.112.20.250)
> >> >>
> >> >>
> >> >> Using horizontal=TRUE with boxplot() confuses it as to what is an
> x- or y-axis.
> >> >> At least, xlim= and ylim= are the wrong way round, log="x" (or "y")
> and xaxt=
> >> >> work as expected, I haven't looked at anything else.
> >> >>
> >> >> Some code to see if you can reproduce the bug (or discover it's in
> my head...):
> >> >>
> >> >> boxplot(count ~ spray, data = InsectSprays)
> >> >>
> >> >> # Try to change x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50))
> >> >>
> >> >> # Plot horizontally:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE)
> >> >>
> >> >> # Now try to change x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE,
> xlim=c(0,50))
> >> >> # Changes y-axis!
> >> >>
> >> >> # Now try to change y-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE,
> ylim=c(0,50))
> >> >> # Changes x-axis!
> >> >>
> >> >> # Plot x-axis on log scale:
> >> >> boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE,
> log="x")
> >> >> # Does indeed change x-axis
> >> >>
> >> >> # Don't add ticks on x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE,
> xaxt="n")
> >> >> # Works as expected.
> >>
> ms> Hi Bob,
> >>
> ms> No, it's not in your head. This is documented in ?bxp, which is the
> ms> function that actually does the plotting for boxplot(). See the
> ms> description of 'pars' in ?bxp:
> >>
> ms> "Currently, yaxs and ylim are used âââ¬ÃÃÅalong the
> boxplotâââ‰â¢, i.e.,
> ms> vertically, when horizontal is false, and xlim horizontally."
> >>
> ms> So essentially, the named 'x' and 'y' axes are rotated 90 degrees when
> ms> you use 'horizontal = TRUE', rather than the vertical axis always
> being
> ms> 'y' and the horizontal axis always being 'x'. This has been discussed
> on
> ms> the lists previously.
> >>
> >> Yes; thank you, Marc.
> >>
> >> And the reason for this is very sensible I think:
> >>
> >> If you have a longish boxplot() or bxp() command,
> >> and you just want to go from vertical to horizontal or vice
> >> versa, it makes most sense just to have to change the
> >> 'horizontal' flag and not having to see if there are other 'x*'
> >> and or 'y*' arguments that all need to be changed as well.
> >>
> JO> Except that you must change xaxt/yaxt and log="x"/log="y" which do not
> JO> follow the "along the box" logic, and behave differently than
> JO> xlim/ylim.
>
> JO> Nothing of this is fatal, but this probably needs more than one
> JO> iteration to find which way each of the x* and y* arguments works.
>
> Oops!!Thank you Jari, for the note.
>
> What you describe is then very unfortunate, and I hadn't been
> aware of that.
>
> ``of course'', making any change to consistency
> would break existing code that consciously works with the
> current mis-"designed" behavior.
>
> But now I understand why we have the word "currently"
> in the description mentioned above.
>
> So given the help file, we should consider dropping the whole
> ``along the boxplot'' idea?
>
> {{well, yes, we should drop "traditional graphics" and work with
> grid-based graphical objects ("grob"s) that can be drawn
> vertically or horizontally,
> e.g., in lattice or (most probably) ggplot2
> }}
>
> Martin
The key code in question, from boxplot.R, seems to be:
if (!add) {
plot.new()
## shall we switch log for horizontal with
## switch(log, x="y", y="x", log) ??
if (horizontal)
plot.window(ylim = xlim, xlim = ylim, log = log, xaxs = pars$yaxs)
else
plot.window(xlim = xlim, ylim = ylim, log = log, yaxs = pars$yaxs)
}
xlog <- (par("ylog") && horizontal) || (par("xlog") && !horizontal)
So it would appear that ylim/xlim and xaxs/yaxs are interchanged when
horizontal = TRUE. All? other axis specific pars remain as per normal.
I have attached a proposed patch against bxp.Rd (against the current svn
copy) for consideration. Hopefully
Re: [Rd] X11 device distortion (PR#10666)
Just to follow up, largely in synch with the two replies already, it sounds like there is a good chance that your two displays (the physical panels or monitors) are either of two different sizes and/or have two different resolutions. Somewhat more likely is the latter. In either case, it is likely that the dpi (dots per inch) setting that is being picked up by the X server is incorrect or biased by one display over the other. Hence, when you open the display device on the screen, the size and aspect ratio of the device is wrong. For example, on my system, I have an internal 15 inch laptop lcd panel of 1600x1200 with a dpi of 133. I have an external 20 inch lcd panel which has the same resolution but at 100 dpi. I happen to use TwinView with an nVidia card, but have to tweak the xorg.conf settings to get the displays to look reasonably similar. I actually hard code the 100 dpi setting rather than allowing the server to get the information from the monitors. My xdpyinfo is: $ xdpyinfo | grep dimensions dimensions:3200x1200 pixels (813x305 millimeters) $ xdpyinfo | grep resolution resolution:100x100 dots per inch Note that using TwinView, my two displays effectively show as one. I would suggest that you post to a SUSE or generic Linux forum or perhaps to a graphics card vendor forum specific to your card for detailed guidance. HTH, Marc Schwartz Hin-Tak Leung wrote: > My first thought was that you must be using Xinerama or TwinView - > and you did mention Xinerama in your r-help message but not > in your bug report - this detail is important. > > That said, I don't know enough about X11 to say anything - well, maybe > I do, but you'll have to show your xorg.conf , and possibly the result > of xdpyinfo for anybody to help you. I think your Xinerama setup is broken. > > for the time being, you could probably run the X11 device through Xnest > to get around this. > > [EMAIL PROTECTED] wrote: >> Full_Name: Thomas Zumbrunn >> Version: 2.6.1 >> OS: GNU/Linux (openSuse 10.3 2.6.22.13-0.3-default) >> Submission from: (NULL) (131.152.125.199) >> >> >> With my particular X11 settings, the width to height ratio of the x11 device >> is >> distorted, with the width being half that of the height. This results in >> wrongly >> proportioned plots, wrongly positioned text etc. >> >> Other devices are not affected. >> >> I already asked about his on the mailing list >> (https://stat.ethz.ch/pipermail/r-help/2007-December/147891.html) but no one >> seemed to have an answer. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Press delete key three times in R-2.6.1 to get segmentation (PR#10898)
[EMAIL PROTECTED] wrote: > Full_Name: Poor Yorick > Version: R-2.6.1 > OS: 2.4.21-50.ELhugemem #1 SMP Tue May 8 17:10:31 EDT 2007 i686 i686 i386 > GNU/Linux > Submission from: (NULL) (148.168.40.4) > > > After compiling R-2.6.1 with gcc-4.2.1 pressing the 'delete' key three times > in > an interactive session causes R to malfunction, spitting out an infinite > stream > of errors. I have also replicated the issue in R-2.5.1: You are specifically asked to not report bugs on obsolete versions of R and to check for prior similar reports. R 2.6.2 is the current version. This has been reported previously (over 2 years ago on R version 2.2.1) and was associated with a bug in readline, which is the underlying functionality that handles getting input from the user in the console. Since you are running a 2.4 series kernel, it suggests that you may also be running an older Linux distribution. Be sure that your system is updated, including the readline libraries, the current version of which is 5.2. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 2006-11-03 at 20:49 +0100, [EMAIL PROTECTED] wrote: > Full_Name: Justin Harrington > Version: 2.4.0 > OS: Fedora Core 6 > Submission from: (NULL) (142.103.121.203) > > > When I type the (albeit stupid) command > > eval(match.call()) > > R crashes with the following messages (truncated): > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > The complete output is available at http://md.stat.ubc.ca/Routput.txt > > For reference, here are the results from version: > > platform i686-redhat-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major 2 > minor 4.0 > year 2006 > month 10 > day03 > svn rev39566 > language R > version.string R version 2.4.0 (2006-10-03) > > and my version of R was installed using yum from the fedora repositories. Hmmm I cannot replicate this using: R version 2.4.0 Patched (2006-10-03 r39576) on FC5: > eval(match.call()) Error in match.call(definition, call, expand.dots) : '.Primitive...' is not a function I'm not running "Zod" yet, but: 1. There have been LOTS of updates to FC6 since release from watching the FC lists. I would be sure that your system is fully updated. 2. You might want to see if compiling and installing 2.4.0 patched from CRAN resolves this behavior at all, though I do not see anything readily evident in the NEWS file to suggest that any fixes are relevant here. 3. If neither of those do anything, it would be worthwhile to file a bug report at RH's Bugzilla against R to see if there is something unique in the version that they are creating in Fedora Extras. Tom Callaway, RH's maintainer for R, does read r-devel, so he may pipe in here also. I have cc'd him on this reply. >From the BT you provided, this looks like it could be a libreadline issue perhaps. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > [EMAIL PROTECTED] writes: > > > Full_Name: Justin Harrington > > Version: 2.4.0 > > OS: Fedora Core 6 > > Submission from: (NULL) (142.103.121.203) > > > > > > When I type the (albeit stupid) command > > > > eval(match.call()) > > > > R crashes with the following messages (truncated): > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > Yes, don't do that then ;-) Indeed... ;-) > Part of the puzzle is that > > > match.call() > match.call() > > which looks like something with potential for infinite recursion, but > that doesn't seem to be issue since > > > f <- function(call = sys.call(sys.parent()))call > > f() > f() > > eval(f()) > f() > > does not exhibit the same crash. And indeed > > > x <- quote(match.call()) > > eval(x) > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > === Backtrace: = > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > /lib/libc.so.6[0x1f0617] > > does look like something that just Should Not Happen... Peter, are you on FC6? On FC5, I cannot replicate your crash: > x <- quote(match.call()) > eval(x) Error in match.call(definition, call, expand.dots) : '.Primitive...' is not a function ? Regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 2006-11-03 at 22:41 +0100, [EMAIL PROTECTED] wrote: > Marc Schwartz <[EMAIL PROTECTED]> writes: > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > x <- quote(match.call()) > > > > eval(x) > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > /lib/libc.so.6[0x1f0617] > > > does look like something that just Should Not Happen... > > Peter, are you on FC6? > > On FC5, I cannot replicate your crash: > > > x <- quote(match.call()) > > > eval(x) > > Error in match.call(definition, call, expand.dots) : > > '.Primitive...' is not a function > > ? > > Yes, I'm on FC6 since yum had updated the 1229 packages this morning. > > I see the crash with the FC6 RPM but not with a self-compiled R-patched. Are you using Martyn's RPM or Extras? Just wondering if there is any difference. In theory, I suppose, given the prior communications with Tom, there shouldn't be. Also, was this a clean install of FC6 or an "in place upgrade" of FC5. Officially, FC does not support the latter and I have seen mixed comments on the FC lists pertaining to that path and associated issues. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Fri, 2006-11-03 at 14:14 -0800, Bill Dunlap wrote: > On Fri, 3 Nov 2006 [EMAIL PROTECTED] wrote: > > > > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > > > x <- quote(match.call()) > > > > > > eval(x) > > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > > > /lib/libc.so.6[0x1f0617] > > > > > > > does look like something that just Should Not Happen... > > > I think valgrind shows the problem is in deparse.c: > 245 strncpy(data, CHAR(STRING_ELT(svec, 0)), 10); > 246 if (strlen(CHAR(STRING_ELT(svec, 0))) > 10) strcat(data, > "..."); > You need to put a '\0' into data[10] after that strncpy > so strcat can find the end of the string when the length > of the copied string is >=10. It currently runs into > uninitialized memory at the end of ".Primitive". > > (This is in a copy of R source from June 2006.) The code is the same, but a couple of lines off in my copy from R 2.4.0 patched. Now lines 247 and 248. Thanks Bill. This would help to explain the difference in behaviors observed. Regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Sat, 2006-11-04 at 02:08 +0100, Peter Dalgaard wrote: > Bill Dunlap <[EMAIL PROTECTED]> writes: > > > On Fri, 3 Nov 2006 [EMAIL PROTECTED] wrote: > > > > > > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > > > > x <- quote(match.call()) > > > > > > > eval(x) > > > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > > > > /lib/libc.so.6[0x1f0617] > > > > > > > > > does look like something that just Should Not Happen... > > > > > > I think valgrind shows the problem is in deparse.c: > > 245 strncpy(data, CHAR(STRING_ELT(svec, 0)), 10); > > 246 if (strlen(CHAR(STRING_ELT(svec, 0))) > 10) strcat(data, > > "..."); > > You need to put a '\0' into data[10] after that strncpy > > so strcat can find the end of the string when the length > > of the copied string is >=10. It currently runs into > > uninitialized memory at the end of ".Primitive". > > > > (This is in a copy of R source from June 2006.) > > Now fixed in 2.4.0 Patched and the development version. Just a quick heads up here, that Tom Callaway has updated the Fedora Extras RPMS to fix the buffer overflow, based upon a post to the FE CVS mailing list last night. This is for FC4, FC5 and FC6. So you can update to these when they appear on FE mirrors in due course. It looks like these should be labelled as 2.4.0-2. Thanks to all. Regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
