[Octave-bug-tracker] [bug #52681] Bad reading for UTF-8 characters with fscanf()

[Dan Sebald]

Follow-up Comment #11, bug #52681 (project octave):

Oy, inside a macro where type-checking isn't obvious.  Well, good find.  Are
there any consequences to this change, in general?

I take it that scanning the character strings from the file (placed in a
temporary std::string, tmp[i] being a signed "char") was transferring them to
double variable types (i.e., "data") which comes out as [-128:127].  Then
translating those back to UTF-8 would *drop* the sign bit, range-limiting to
[0:127]?

And that is why after seeing the


warning: range error for conversion to character value


message the UTF-8 characters are broken?:


a =
{
  [1,1] = Pas
}

c =
{
  [1,1] = Poblacin
}


I guess I'm wondering if there are any instances where we do want to treat
characters as signed numbers.  Having some sort of cast within a macro tends
to make the macro specific rather than general.  For example, this
FINISH_CHARACTER_CONVERSION() is used for %c, %s and [] format types.  Might
we want %c to be treated as signed?  If so, you could make a macro variable


#define FINISH_CHARACTER_CONVERSION(TYPECAST)
[snip]
  data[data_index++] = static_cast<TYPECAST>  \


such that it becomes


          case 's':
            {
              BEGIN_S_CONVERSION ();

              FINISH_CHARACTER_CONVERSION (unsigned char);
            }
            break;


or something similar.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52681>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/