Wed 14 Aug 2013 02:56:41 PM UTC, comment #11:
Ok, if the behaviour is similar to MATLAB I stop complaining.
|
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.
|
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.
|
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?
|
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.
|
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).
|
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.
|
Wed 14 Aug 2013 11:54:02 AM UTC, comment #4:
Looks fine to me. Thanks.
|
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
|
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.
|
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.
|
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?
|