search for: rm_eo

...gt;> Duncan Murdoch <murdoch.duncan at gmail.com> ?????: >> >>> gsub("^([0-9]{,5}).*","\\1","123456789") >>> [1] "123456" >> This is in TRE itself: for "^([0-9]{,1})" tre_regexecb returns {.rm_so >> = 0, .rm_eo = 1}, matching "1", but for "^([0-9]{,2})" and above it >> returns an off-by-one result, {.rm_so = 0, .rm_eo = 3}. >> >> Compiling with TRE_DEBUG, I see it parsed correctly: >> >> catenation, sub 0, 0 tags >> assertions: bol >> i...

...ch <murdoch.duncan at gmail.com> ?????: >>> >>>> gsub("^([0-9]{,5}).*","\\1","123456789") >>>> [1] "123456" >>> This is in TRE itself: for "^([0-9]{,1})" tre_regexecb returns {.rm_so >>> = 0, .rm_eo = 1}, matching "1", but for "^([0-9]{,2})" and above it >>> returns an off-by-one result, {.rm_so = 0, .rm_eo = 3}. >>> >>> Compiling with TRE_DEBUG, I see it parsed correctly: >>> >>> catenation, sub 0, 0 tags >>> ??? assert...

...e inconvenient character code which used 0x5c after the first byte. --- R-2.5.0.orig/src/main/character.c 2007-04-03 11:05:05.000000000 +0900 +++ R-2.5.0/src/main/character.c 2007-06-24 22:31:06.000000000 +0900 @@ -986,6 +986,17 @@ char *p = repl; n = strlen(repl) - (regmatch[0].rm_eo - regmatch[0].rm_so); while (*p) { +#ifdef SUPPORT_MBCS + if(mbcslocale){ + int clen; + mbstate_t mb_st; + mbs_init(&mb_st); + if((clen = Mbrtowc(NULL, p, MB_CUR_MAX, &mb_st)) > 1){ + p+=clen; + continue; +...

...but probably Chris or someone else should sign > off on it. This seems ok to me, please commit. One minor comment: +++ b/lib/Support/Regex.cpp + // Allocate pmatch with at least one element. + pmatch = new llvm_regmatch_t[nmatch > 0 ? nmatch : 1]; + pmatch[0].rm_so = 0; + pmatch[0].rm_eo = String.size(); Can this be a smallvector to avoid a heap allocation on every match? -Chris

On StackOverflow (here: https://stackoverflow.com/questions/78803652/why-does-gsub-in-r-match-one-character-too-many) there was a question about this result: > gsub("^([0-9]{,5}).*","\\1","123456789") [1] "123456" The OP expected "12345" as the result. Several points were raised: - The R docs don't mention the case of {,5} for the

...othly under rpy and RSPython and only certain functions elicit the error. For instance, doing "bitmap('file.bmp')" will cause a segfault in do_strsplit (character.c:260) because the regmatch structure contains the nonsense values: (gdb) print regmatch[0] $1 = {rm_so = 9257728, rm_eo = 9257729} With R 1.5.0, R fails to complete startup initialization under both rpy and RSPython, segfaulting in do_readDCF (dcf.c:109) with similar nonsense values in the regmatch structure: (gdb) print regmatch $7 = {{rm_so = 9777896, rm_eo = 9777905}} Does anyone have asuggestion on the be...

...arsing this directly in RE. strpbrk() helps */ if (iface != NULL) - strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstvuwxyz0123456789")); + strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789")); memset(tmp, 0, matches[i].rm_eo - matches[i].rm_so); } -- Miroslav Rezanina Software Engineer - Virtualization Team - XEN kernel

Full_Name: Roger Bivand Version: 0.99.0 OS: RH Linux 6.1 Submission from: (NULL) (158.37.60.152) I am working on an interface between R and the GRASS geographical information system, written in R, with no dynamically loaded code. I have written full examples, and tested then under R 0.90.1, both by entering example() for each function and R CMD check, both of which worked without problem. Under

...ot;-Ae" ignored. cc: "../include/regex.h", line 50: error 1000: Unexpected symbol: "regoff_t". cc: "../include/regex.h", line 60: error 1000: Unexpected symbol: "regoff_t". cc: "../include/regex.h", line 61: error 1000: Unexpected symbol: "rm_eo". cc: "../include/regex.h", line 62: error 1000: Unexpected symbol: "}". cc: "../include/regex.h", line 105: error 1000: Unexpected symbol: "regmatch_t". cc: "../include/regex.h", line 61: warning 557: Missing declaration specifiers, "int&...

Nice! This looks good to me but probably Chris or someone else should sign off on it. There were two minor warnings on Darwin: -- In file included from /Volumes/Data/Users/ddunbar/llvm/lib/Support/regexec.c:81: /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc: In function 'sbackref': /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc:665: warning: control reaches end of

...m/Support/IRBuilder.h(133) : error C3861: 'InsertHelper': identifier not found > > +++ b/lib/Support/Regex.cpp > > + // Allocate pmatch with at least one element. > + pmatch = new llvm_regmatch_t[nmatch > 0 ? nmatch : 1]; > + pmatch[0].rm_so = 0; > + pmatch[0].rm_eo = String.size(); > > Can this be a smallvector to avoid a heap allocation on every match? Yes, I changed it to use SmallVector. Best regards, --Edwin

.../* FIXME: reorganize this as a memcpy */ graphics.c- -- grep.c:/* FIXME: make more robust, and public */ grep.c-static SEXP mkCharWLen(const wchar_t *wc, int nc) -- grep.c: strings, but <MBCS-FIXME> it would be more grep.c- efficient to skip along by chars. -- grep.c: if (ptag.rm_eo == 0) { /* empty string matched => trouble; FIXME: we may want to consider just advancing anyway */ grep.c- int infinite_match = 1; -- grep.c:/* FIXME: use UCP for upper/lower conversion */ grep.c-static -- grep.c: /* FIXME perhaps we ought to check validity here */ grep.c- len = strlen(str...

...len--; > - } > - p[len] = 0; > - > - /* test the regular expression */ > - r = regexec(preg, p, 1, pmatch, 0); > - free(p); > - if (r) { > - return 0; > - } > - /* check that the match is the entire string */ > - if (pmatch[0].rm_so != 0 || pmatch[0].rm_eo != len) { > - return 0; > - } > - return 1; > + * entire string str (minus any initial and trailing whitespace) > + * matches the compiled regular expression preg. Return 1 if it > + * matches, 0 if not. Return -1 on error with errno set. Special > + * cases: if preg==NULL...

This patch series copies the core of the tapdisk process from blktap2, with updates coming from blktap2.5. Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>