From Bugzilla Helper:
User-Agent: Mozilla/4.72 [muriyari-ja] (X11; U; Linux 2.2.14-5.0 i686)
Description of problem:
Steps to Reproduce:
1. Run gnumeric in Japanese environment(LANG=ja_JP.eucJP)
2. Insert a columun.
Actual Results: SIGSEGV
Expected Results: Insert the column.
ja.po in gnumeric says(write Japanese part in alphabet):
msgid "Inserting %d column before %s"
msgstr "%2$s no maeni %1$d retsu wo sounyuu"
but glib doesn't support %2$s type so gnumeric crashes.
glib should support this. See 871 line in glib-1.2.9/gstrfuncs.c
This bug also occurs on the gnumeric in the Korean
(Summary fix: not glibc but glib)
This is _extremely_ hard to do. Basically, to do it portably, you
either have to:
- Ship a complete printf() implementation with GLib to be
used on systems where stdio doesn't support positional
parameters. Since handling things like float formatting
is highly non-trivial, I'd be quite reluctant to do this.
- Know how to portably rewrite valists when passing
them to vsprintf().
At some point in the future, we may just require a C library
with support for positional parameters. However, since positional
parameters are NOT part of ISO C99, though they are part
of SUSv2, and we do care about portability to non-Unix systems
now, I don't imagine we'll be doing this any time soon.
For now it should be just be treated as a limitation in GLib. :-(
g_printf_string_upper_bound() just returns the total length.
If glib doesn't support this, I want another idea of replacement.
Many developer will use this.
It's easy to make it work on Red Hat, on Linux, on modern Unix.
However, then .po files that work on Linux, will suddenly not
work and most likely segfault on other operating systems.
Since the translations we make should always be sent upstream
to the original package maintainers, and since most of
the packages we ship that use GLib are not Linux specific,
I don't see that adding positional parameters to g_strdup_sprintf(),
has significant value.
Created attachment 19371 [details]
a code to crash.
Attached is a code to crash with glib.
I think it is very silly that it crashes in a function that just
returns the length.
Created attachment 19372 [details]
And this is a simple patch for glib.
Agreed, it would be better to skip the entire format specifier
(Note that the patch above doesn't seem to handle things like
I've filed this as:
Is this fixed for Hampton?
GLib-1.2 behaves as you did before ... you can't use positional parameters.
GLib-2.0 has some changes so that (on sufficiently modern Unix-like systems)
you can use whatever capabilities the native printf has.
Not going to do anything on glib-1.2 at this point. In Glib-2.2, Glib
will always provide positional parameter support; if the C library
doesn't support it, it includes a copy of the 'trio' library.