search for: r_eof

...can.c.orig Wed Sep 29 11:11:45 1999 +++ R-0.65.1/src/main/scan.c Fri Oct 29 17:34:22 1999 @@ -124,7 +124,7 @@ if (bufp >= &buffer[MAXELTSIZE - 2]) continue; *bufp++ = c; - } while (!isspace(c = scanchar()) && c != R_EOF); + } while ((c = scanchar()) != R_EOF && !isspace(c)); while (c==' ' || c=='\t') c=scanchar(); if (c=='\n' || c=='\r' || c==R_EOF) @@ -647,7 +647,7 @@ } } else { -...

...n_t nmax, nlines, nskip; const char *p, *encoding; RCNTXT cntxt; @@ -952,7 +952,7 @@ if(!data.con->canread) error(_("cannot read from this connection")); } - for (R_xlen_t i = 0; i < nskip; i++) /* MBCS-safe */ + for (R_xlen_t i = 0; i < nskip && c != R_EOF; i++) /* MBCS-safe */ while ((c = scanchar(FALSE, &data)) != '\n' && c != R_EOF); } Making it interruptible is a bit more work: we need to ensure that a valid context is set up and check regularly for an interrupt. --- src/main/scan.c (revision 83797) +++ src/main...

...op?on?EOF. Alternatively,?not?using?nested?loop?is?possible,?like?the?following. ?if?(nskip)?for?(R_xlen_t?i?=?0,?j?=?10000;?;?)?{?/*?MBCS-safe?*/ ?c?=?scanchar(FALSE,?&data); ?if?(!j--)?{ ?????R_CheckUserInterrupt(); ?????j?=?10000; ?} ?if?((c?==?'\n'?&&?++i?==?nskip)?||?c?==?R_EOF) ?????break; ?} ----------- On?2/11/23?09:33,?Ivan?Krylov?wrote: >?On?Fri,?10?Feb?2023?23:38:55?-0600 >?Spencer?Graves?<spencer.graves?using?prodsyse.com>?wrote: > >>?I?have?a?4.54?GB?file?that?I'm?trying?to?read?in?chunks?using >>?"scan(...,?skip=__)".??I...

Hello, All: I have a 4.54 GB file that I'm trying to read in chunks using "scan(..., skip=__)". It works as expected for small values of "skip" but goes into an infinite loop for "skip=1e11" and similar large values of skip: I cannot even interrupt it; I must kill R. Below please find sessionInfo() with a toy example. My real problem is a large

It happens in the token function in gram.c:     c = SkipSpace();     if (c == '#') c = SkipComment(); and then SkipComment goes like that: static int SkipComment(void) {     int c;     while ((c = xxgetc()) != '\n' && c != R_EOF) ;     if (c == R_EOF) EndOfFile = 2;     return c; } which effectively drops comments. Would it be possible to keep the information somewhere ? The source code says this:  *  The function yylex() scans the input, breaking it into  *  tokens which are then passed to the parser.  The lexical  ...

...> TEXT_PUSH('\\'); TEXT_PUSH('v'); TEXT_PUSH('e'); TEXT_PUSH('r'); > TEXT_PUSH('b'); > TEXT_PUSH(c); > - while ((c = xxgetc()) != delim) TEXT_PUSH(c); > - TEXT_PUSH(c); > + while (((c = xxgetc()) != delim) && c != R_EOF) TEXT_PUSH(c); > + if (c != R_EOF) TEXT_PUSH(c); > > PRESERVE_SV(yylval = mkString2(stext, bp - stext)); > if(stext != st0) free(stext); > > This seems to have been the only remaining while loop in gramLatex.y > that didn't check for R_EOF. > > More corre...

Hello, I do not have an account on R Bugzilla, so I will post my bug report here. I want to report a very old bug in base R *source()* function. It relates to sourcing some R scripts in UTF-8 encoding on Windows machines. For some reason if the UTF-8 script is containing cyrillic letter *"?"*, the script execution is interrupted directly on this letter (btw the same scripts are sourcing

...articular value causes trouble for the R parser, which uses a stack of previously-seen characters (include/Defn.h): LibExtern char R_ParseContext[PARSE_CONTEXT_SIZE] INI_as(""); And at various places checks whether the context character is EOF. That character is defined as #define R_EOF -1 Which, when cast to a char, is 0xFF. I suspect that your example is revealing two bugs: 1) The R parser seems to have trouble with native characters encoded as 0xFF. It's possible that, since R strings can't contain 0x00, this can be fixed by changing the definition of R_EOF to...

...ossible to obtain a cross-platform solution or not. I located the following native do_readln() function in src/main/scan.c that is called by readline(): SEXP attribute_hidden do_readln(SEXP call, SEXP op, SEXP args, SEXP rho) { ... while ((c = ConsoleGetchar())!= '\n' && c != R_EOF) { if (bufp >= &buffer[MAXELTSIZE - 2]) continue; *bufp++ = c; } ... } with ConsoleGetchar(): /* used by readline() and menu() */ static int ConsoleGetchar(void) { if (--ConsoleBufCnt < 0) { ConsoleBuf[CONSOLE_BUFFER_SIZE] = '\0'; if (R_ReadConsole(ConsolePrompt,...

...+42,12 @@ /* Use R_alloc as this might get interrupted */ static char *Rconn_getline2(Rconnection con) { - int c, bufsize = MAXELTSIZE, nbuf = -1; + int c, bufsize = MAXELTSIZE, nbuf = 0; char *buf; buf = R_alloc(bufsize, sizeof(char)); while((c = Rconn_fgetc(con)) != R_EOF) { - if(nbuf+2 >= bufsize) { // allow for terminator below + if(nbuf+1 >= bufsize) { // allow for terminator below bufsize *= 2; char *buf2 = R_alloc(bufsize, sizeof(char)); memcpy(buf2, buf, nbuf); @@ -54,17 +54,19 @@ buf = buf2; } if(c != '\n'){ -...

...get interrupted */ > static char *Rconn_getline2(Rconnection con) > { > - int c, bufsize = MAXELTSIZE, nbuf = -1; > + int c, bufsize = MAXELTSIZE, nbuf = 0; > char *buf; > > buf = R_alloc(bufsize, sizeof(char)); > while((c = Rconn_fgetc(con)) != R_EOF) { > - if(nbuf+2 >= bufsize) { // allow for terminator below > + if(nbuf+1 >= bufsize) { // allow for terminator below > bufsize *= 2; > char *buf2 = R_alloc(bufsize, sizeof(char)); > memcpy(buf2, buf, nbuf); > @@ -54,17 +54,19 @@ > buf = buf2;...

Dear R developers, I have found the following bug with readline() in R 0.63.3: if you execute the menu-function and then the readline() function, then readline() prompts "Selection:" > a <- readline() hello > a [1] "hallo" > a <- menu(c("a", "b"), title="bitte:") bitte: 1:a 2:b Selection: 2 > a <- readline() Selection:

Here's an update: I checked the ChangeLog for R, and it seems like readDCF was changed in 3.0.2. I went on a whim and copied src/main/dcf.c from R 2.15.3 over to 3.2.2, and R compiled fine and install.packages now work for me. This is probably not ideal, but it at least makes R usable on AIX for me. Would definitely like to help figure out what's wrong with the new dcf.c on AIX.

...Date: Thu, 28 Oct 1999 17:23:02 +0100 (BST) * PR# 302 * Subject: modreg buggy: uninitialized variable in sinerp.f From: "Thomas Hoffmann" <thoffman@zappa.sax.de> Date: Sat, 30 Oct 99 13:24:14 +0100 * PR# 303 * Subject: read.table problem on Linux/Alpha (seg faults caused by isspace(R_EOF)) From: ntakebay@bio.indiana.edu Date: Sun, 31 Oct 1999 01:29:05 +0200 (MET DST) * PR# 304 * Subject: bugs in scan() From: Ray Brownrigg <Ray.Brownrigg@mcs.vuw.ac.nz> Date: Mon, 1 Nov 1999 12:20:33 +1300 (NZDT) * PR# 305 * Subject: bug in sample From: Robert Gentleman <rgentlem@jimmy.harva...