#187 [PATCH] Handling of locale (LC_*) is wrong

closed-fixed
Joe Allen
None
9
2008-11-08
2007-01-03
Jan Engelhardt
No

This is the same as
http://sourceforge.net/tracker/index.php?func=detail&aid=1572000&group_id=23475&atid=378598
I wanted to bring to attention since it seems unhandled since October.

Discussion

  • Jan Engelhardt
    Jan Engelhardt
    2007-01-03

    • assigned_to: nobody --> jhallen
     
  • Jan Engelhardt
    Jan Engelhardt
    2007-01-03

    Logged In: YES
    user_id=1287009
    Originator: YES

    Explicitly assigning to jhallen. (BTW, Is not your tracker set up to do that automatically?)

     
  • Jan Engelhardt
    Jan Engelhardt
    2007-01-03

    Fix it

     
  • Jan Engelhardt
    Jan Engelhardt
    2007-01-03

    • priority: 5 --> 9
    • summary: [2] Handling of locale (LC_) is wrong --> [PATCH] Handling of locale (LC_) is wrong
     
  • Jan Engelhardt
    Jan Engelhardt
    2007-01-03

    Logged In: YES
    user_id=1287009
    Originator: YES

    Here's a patch, please include.
    BTW, why do you all need those "unsigned char" in the code?
    File Added: joe-3.5-fix_locale.diff

     
  • Joe Allen
    Joe Allen
    2007-01-03

    Logged In: YES
    user_id=1000448
    Originator: NO

    I will start working on JOE again soon- so keep the bug reports and patches coming. As long as they are in the tracker I will see them.

    I use 'unsigned char' because I want conversions from char to int to not result in negative numbers, which is almost always a bug. Although initial coding with unsigned char is a pain, I can mechanically verify that this bug does not exist this way.

     
  • Josip Rodin
    Josip Rodin
    2008-06-07

    Logged In: YES
    user_id=119756
    Originator: NO

    I investigated that code a bit, and I can't say I really understand
    what the hell it is doing, that is, why it's doing it :)

    I checked the documentation for setlocale(), and cross-checked the
    implementations in vim, nano, jed, and none of them do what joe seems to be
    doing - joe is trying to read a "non-UTF8 but local" codepage by checking
    the environment and switching to that locale, and then reading a "UTF8 but
    local" codepage by doing the standard setlocale(LC_ALL, "") call.

    During the first part of that process, joe checks these variables in turn:
    LC_ALL, LC_CTYPE, LANG. It seems that others either don't do that, or they
    check LC_MESSAGES instead of LC_CTYPE.

    The codepages it goes to so much pain to extract are used to read
    the /etc/joe/charmaps/* files, but there's only "klingon" in there.

    I tested the process with various inputs, and every the time the first part
    of the process would return the default C codepage, except when the user
    sets LC_CTYPE to e.g. de_DE, and the second part would do the right thing.

    This whole codepage business sounds like a classic case of too much pain
    for too little gain...

    The patch in here seems to be redundant. It adds another discovery procedure
    for the locale_lang variable (which gets passed into init_gettext(), the function
    which seeds the joe custom .po implementation), just because the existing
    procedure fixates on LC_CTYPE. We should fix the old procedure rather than add
    yet another new one which further complicates the code for no apparent reason.

    CVS history shows that there has been considerable ambiguity on this front in the
    past - Joseph has actually left in a broken version of the CODESET getting procedure
    in the latest commit:

    http://joe-editor.cvs.sourceforge.net/joe-editor/joe-current/utf8.c?r1=1.26&r2=1.27

    The ifndef CODESET -> undef HAVE_SETLOCALE calls *must* go after the loading of <langinfo.h>,
    because otherwise the CODESET from that file is always ignored.

    Most if not all the other commits in this part of the code show the back-and-forth:
    http://joe-editor.cvs.sourceforge.net/joe-editor/joe-current/utf8.c?r1=1.24&r2=1.25
    http://joe-editor.cvs.sourceforge.net/joe-editor/joe-current/utf8.c?r1=1.19&r2=1.20
    http://joe-editor.cvs.sourceforge.net/joe-editor/joe-current/utf8.c?r1=1.14&r2=1.15
    http://joe-editor.cvs.sourceforge.net/joe-editor/joe-current/utf8.c?r1=1.2&r2=1.3
    http://joe-editor.cvs.sourceforge.net/joe-editor/joe-current/utf8.c?r1=1.1&r2=1.2

    It would be good if we had an explanation of what the code is actually trying to do. :)

     
  • Joe Allen
    Joe Allen
    2008-10-25

    This is now fixed in CVS.

     
  • Joe Allen
    Joe Allen
    2008-10-25

    • status: open --> closed
     
  • Jan Engelhardt
    Jan Engelhardt
    2008-11-08

    • status: closed --> closed-invalid
     
  • Jan Engelhardt
    Jan Engelhardt
    2008-11-08

    Yeah, it's fixed now.

     
  • Jan Engelhardt
    Jan Engelhardt
    2008-11-08

    • status: closed-invalid --> closed-fixed
     
  • Jan Engelhardt
    Jan Engelhardt
    2008-11-08

    (Fixed in 3.6 and up, though I only tested 3.7 because it was released shortly after 3.6.)