After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 737137 - g_option_context_parse() with an UTF-8 G_OPTION_ARG_FILENAME fails
g_option_context_parse() with an UTF-8 G_OPTION_ARG_FILENAME fails
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: general
2.40.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-09-22 18:11 UTC by Canek Peláez Valdés
Modified: 2014-09-22 20:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case showing the bug (1.49 KB, text/x-csrc)
2014-09-22 18:11 UTC, Canek Peláez Valdés
Details

Description Canek Peláez Valdés 2014-09-22 18:11:13 UTC
Created attachment 286837 [details]
Test case showing the bug

The attached program shows that g_option_context_parse() fails when a GOptionEntry of type G_OPTION_ARG_STRING is provided with an UTF-8 string including characters not in ASCII, giving the error "Invalid byte sequence in conversion input (g_convert_error, 1)".

I can workaround this issue by specifying the type of the GOptionEntry to G_OPTION_ARG_STRING, but I would prefer it to be properly set as string.

Gentoo Linux up to date, glib-2.40.0. Try the test case with:

# This is just an example, it fails with any UTF-8 string
# with characters not in ASCII
$ ./test -o 'ñ'

** (test:21267): WARNING **: file test.c: line 32: unexpected error: Invalid byte sequence in conversion input (g_convert_error, 1)
Argument 1: ./test
Argument 2: -o
Argument 3: ñ
Comment 1 Canek Peláez Valdés 2014-09-22 18:33:56 UTC
Sorry, the second paragraph is:

"I can workaround this issue by specifying the type of the GOptionEntry to
G_OPTION_ARG_FILENAME, but I would prefer it to be properly set as string."

Sorry for the confusion.
Comment 2 Allison Karlitskaya (desrt) 2014-09-22 19:46:40 UTC
[desrt@humber ~]$ ./test ĝuste?
Argument 1: ./test
Argument 2: ĝuste?


Seems to work for me.

Is your locale set to utf-8 properly?  We try to convert from your locale to utf-8, so maybe that's the issue.

What is the output of 'locale'?
Comment 3 Canek Peláez Valdés 2014-09-22 19:49:27 UTC
(In reply to comment #2)
> [desrt@humber ~]$ ./test ĝuste?
> Argument 1: ./test
> Argument 2: ĝuste?
> 
> 
> Seems to work for me.

Yeah, *that* works here too. Try this please:

[desrt@humber ~]$ ./test -o ĝuste?

> Is your locale set to utf-8 properly?  We try to convert from your locale to
> utf-8, so maybe that's the issue.

I believe my locale es setup properly.

> What is the output of 'locale'?

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.utf8
LC_TIME=en_US.utf8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.utf8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.utf8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=es_MX.utf8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Comment 4 Allison Karlitskaya (desrt) 2014-09-22 19:55:49 UTC
Sorry -- my bad.  I was able to reproduce.

The problem is that you really are in a C locale, at least in this program.

You need to call setlocale(LC_ALL, ""); at the start of main in order to initialise the locale system.

Once I make that change, everything works fine.
Comment 5 Canek Peláez Valdés 2014-09-22 20:24:40 UTC
Thank you.