bugGNU Octave - Bugs: bug #33258, regexprep with empty replacement...

 
 

bug #33258: regexprep with empty replacement gives an error (not sure what cases)

Submitted by:  None
Submitted on:  Sat 07 May 2011 02:02:57 PM UTC  
 
Category: LibrariesSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Performance
Status: FixedAssigned to: None
Originator Name: Jochen WeberOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 3.4.0
Operating System: Mac OS

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 27 Oct 2011 04:34:11 AM UTC, comment #5:

I believe I've fixed the problem with null patterns in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/c4b6ea833fa5). You will need to build from development sources or wait until the 3.6 release scheduled for December 2011 to see the change.

Rik <rik5>
Project Administrator
Thu 16 Jun 2011 12:45:55 PM UTC, comment #4:

replacement of * with + solves the problem.
These are different 'operators' of course, but I thought that * also matches 0 occurrences, it could be related to some size problem of the string.

kloof <kloof>
Wed 15 Jun 2011 11:58:49 AM UTC, comment #3:

Dear Jochen,

I get the same type of error when using 'regexprep' on a string. Adding a space before or after the string does not resolve the problem for me.

I have compiled 3.4.0 with gcc on ubuntu linux 11.04 (on a MBP 6,2) with:

$> dpkg --list |grep pcre
ii libpcre++-dev 0.9.5-5 C++ wrapper class for pcre (development)
ii libpcre3 8.12-3ubuntu2 Perl 5 Compatible Regular Expression Library - runtime files
ii libpcre3-dev 8.12-3ubuntu2 Perl 5 Compatible Regular Expression Library - development files
ii libpcrecpp0 8.12-3ubuntu2 Perl 5 Compatible Regular Expression Library - C++ runtime files
$>

no matter what string I process with regexrep, I alway get error '-24'.

Is there a way to debug this in more detail than what you've done sofar?

kloof <kloof>
Sun 08 May 2011 12:36:57 AM UTC, comment #2:

Quite possible... For my Octave 3.4.0 version (I downloaded a .dmg file, as I don't have the necessary tools installed to compile on my Macbook...), the filenames suggest a very early lib for PCRE.

Most filenames in the $INSTALL/Contents/Resources/lib subfolder have a "reasonable" version number in the filename (e.g. libfftw3.3.1.2.dylib), but the PCRE libs are:

libpcre.0.0.1.dylib
libpcrecpp.0.0.0.dylib
libpcreposix.0.0.0.dylib

(with filedates being all Oct 1 2009) suggesting that the PCRE libraries better be updated by the Mac OSX Octave maintainer ;)

Thanks for pointing this out! (I fixed the questionable expression match patterns, and now there are no more error messages).

For those interested, the package (toolbox, developed under Matlab v7.5 through v7.11) that I'm developing is available under http://neuroelf.net/ and I'm now trying to get as much functionality working in Octave as possible. Unfortunately, the GUI functions (figure, uicontrol, etc.) are currently too diversely supported (JHandles, java not available for all platforms/newest Octave release; some function calls not supported as with Matlab, such as figure(FIG_PROP_STRUCT); to create a figure with all properies set, incl. the CreateFcn, for instance!). The command line functionality start to be "usable", but there is still a long way to go...

Cheers,
/jochen

Jochen Weber <jweber>
Sun 08 May 2011 12:20:10 AM UTC, comment #1:

I'm unable to reproduce this, but I'm also working on a Linux platform. It could be that the PCRE library you have has an issue. For reference, I'm running libpcre3-7.8-3.

Rik <rik5>
Project Administrator
Sat 07 May 2011 02:02:57 PM UTC, original submission:

I stumbled across this error when using the syntax:

If TEXTVAR contains at least one space character at the end, no error occurs. If, however, no spaces are at the end, I receive an error:

I understand that the pattern should be more correct:

which works fine. So I'm not sure how much of a "coding" problem (on my part) this is, but I would still say that this should not happen:

Matlab handles these cases fine (no replacement, as the pattern is, in effect, empty). I don't know how much control you have when calling the PCRE library functions, but I think it would be nice to not have an error thrown if the pattern resolves to an empty string (hence Item Group Improvement/Optimization...).

Cheers,
/jochen

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by kloof (Posted a comment)
  • -unavailable- added by jweber (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 27 Oct 2011 04:34:11 AM UTCrik5StatusWorks For Me=>Fixed
      Open/ClosedOpen=>Closed
    Sun 08 May 2011 12:20:10 AM UTCrik5StatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup1