bugGNU Octave - Bugs: bug #39775, Consistent treatment of octal and...

 
 

bug #39775: Consistent treatment of octal and hexadecimal escape sequences in double-quoted strings

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Mon 12 Aug 2013 06:53:02 PM UTC  
 
Category: InterpreterSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Feature Request
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Wed 14 Aug 2013 02:56:41 PM UTC, comment #11:

Ok, if the behaviour is similar to MATLAB I stop complaining.

Stefan Mahr <dac922>
Wed 14 Aug 2013 02:36:28 PM UTC, comment #10:

It appears that Matlab does not limit to two, but does warn if the result is outside the range of possible character values (and then proceeds to fail to perform any conversion at all). How about doing that?

Here's a test you can try:

Note that leading zeros are allowed, so it is not just about counting digits and limiting them to 2, 4, or whatever.

John W. Eaton <jwe>
Project Administrator
Wed 14 Aug 2013 02:19:52 PM UTC, comment #9:

For now, yes, because that's exactly how a C parser would also treat those strings. I'm thinking about it and I may change my mind. The Perl and Python parsers limit to 2 hex characters.

If we do support wide characters some day, what would be the proper escape sequence to produce one character if \\x were to only allow two characters?

Depending on how my companion bug #39774 turns out, we may want to limit to 2 for compatibility reasons. I don't know yet how Matlab's fprintf behaves with \\o and \\x, but if it strictly limits the number of characters, we may want to do the same for double-quoted strings just so the same string parses the same way whether it's single- or double-quoted.

Mike Miller <mtmiller>
Project Administrator
Wed 14 Aug 2013 02:03:22 PM UTC, comment #8:

You are right, I should read the comments more careful.

However, there is a general problem with variable size:

Do we really want such 'undefined' behaviour?

Stefan Mahr <dac922>
Wed 14 Aug 2013 01:42:06 PM UTC, comment #7:

Yes, that was the intent. I started with {1,2}, but then I saw the note in the commented-out documentation that suggested the C behavior of accepting any number of hex characters, so I went that way.

I don't have a problem with someone passing a ridiculous number of hex characters and getting an unexpected char produced in the string. If someone can show that this may crash or corrupt memory, then I'm all for changing it.

But the intent was to behave like C, which does definitely allow sequences like that.

Mike Miller <mtmiller>
Project Administrator
Wed 14 Aug 2013 01:20:34 PM UTC, comment #6:

The comment in the code and the explanation in the documentation does say that the value produced by more than two hex digits is implementation defined, same as for C and C++, so the current behavior seems fine to me.

But I don't care too much one way or the other. An error would also be OK with me.

Note that someday we may make characters 16 bits wide for compatibility with Matlab. So 2 is the limit now, but might not be in the future.

I also don't think that forcing 2 characters to be used is better than allowing 1 or 2 (or 3 or 4).

John W. Eaton <jwe>
Project Administrator
Wed 14 Aug 2013 01:06:18 PM UTC, comment #5:

You you really want to allow \x[0-9a-fA-F]+ ?

I don't think this will fit to (int) result: \x0102030405060708090a0b0c

I suggest to use {1,2} or even better fixed {2} for hex values.

Stefan Mahr <dac922>
Wed 14 Aug 2013 11:54:02 AM UTC, comment #4:

Looks fine to me. Thanks.

John W. Eaton <jwe>
Project Administrator
Wed 14 Aug 2013 06:13:09 AM UTC, comment #3:

Thanks. I was going to submit a patch since this is my first time working with the parser, but it turned out to be surprisingly easy to implement. I went ahead and pushed the following changeset to add this feature:

http://hg.savannah.gnu.org/hgweb/octave/rev/9de751a10910

Mike Miller <mtmiller>
Project Administrator
Tue 13 Aug 2013 08:09:25 PM UTC, comment #2:

It seems fine to me to do hex escape processing. For Matlab compatibility reasons, this treatment should only be given to double quoted strings.

John W. Eaton <jwe>
Project Administrator
Mon 12 Aug 2013 07:06:49 PM UTC, comment #1:

I forgot to give an example, here is the current behavior of Octave. The expected behavior is that all 3 assignments result in the same string.

Mike Miller <mtmiller>
Project Administrator
Mon 12 Aug 2013 06:53:02 PM UTC, original submission:

As far as I can tell, Octave's parser currently handles octal escape sequences in double-quoted strings but not hexadecimal escape sequences. It would be desirable to handle both to be consistent with C/Perl/Python/etc and to be consistent with escape sequences handled by printf/fprintf/sprintf (see also bug #39774).

Also the Octave manual describes the NUL byte as the only valid octal escape sequence in the section on escape sequences "doc escape", but in fact any octal constant works currently.

Would this added feature break compatibility or not be desirable for any reason?

Mike Miller <mtmiller>
Project Administrator

 

(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 dac922 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by mtmiller (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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 14 Aug 2013 06:13:09 AM UTCmtmillerStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1