Re: setlocale() bugs
Hi Karl,
Karl Williamson wrote on Sat, Mar 31, 2018 at 11:50:16AM -0600:
>> Karl Williamson wrote on Mon, Mar 19, 2018 at 11:51:31AM -0600:
>>> (And to be
>>> consistent, LC_ALL should have been the heterogenous composition of all
>>> the locale strings that the program sets, even if they just boil down to
>>> C or UTF-8. Programs that run on other OS's are expecting this, and
>>> again your portability goal is compromised)
I'm calling this paragraph [*] for later reference.
> If I set LC_CTYPE to foo, and LC_COLLATE to bar, and then request
> setlocale(LC_CTYPE, NULL), it returns 'foo', and
> setlocale(LC_COLLATE, NULL), it returns 'bar', even though that's not
> really true. I understand why you do that, but I claim that you should
> maintain consistency when asking for
> setlocale(LC_ALL, NULL)
> Currently it just says 'C', but code from other systems would be
> expecting it to act as if the previous calls actually took effect.
> In Linux it would return
> LC_CTYPE=foo;LC_COLLATE=bar;LC_NUMERIC=C...
> And I think you should do something similar, so that what gets returned
> by LC_ALL reflects what previous individual setlocale's have done.
That's exactly what i fixed with my recently committed patch,
see the the first part of the test program appended below.
> Right now, if you set LC_CTYPE to foo, then call
> const char * save=setlocale(LC_ALL, NULL);
> to save things, then change LC_CTYPE to baz, then call
> setlocale(LC_ALL, save)
> printf("%s\n", setlocale(LC_CTYPE,NULL)
> I don't believe it will be foo because your LC_ALL returned a value that
> didn't contain 'foo'.
That appears to work as expected, too, after my commit,
see the the second part of the test program appended below.
So you think what you meant with [*] is now completely resolved?
> If this isn't clear, let me know.
I *think* i got your points now - it would be appreacited if you could
either confirm that or point me to whatever i'm still missing.
> Your setlocale is a stub, but it should act consistently.
I would call it a stub - it does everything required by the POSIX
standard (modulo the bugs that i just fixed, and any that might
still remain to be fixed). What it doesn't implement is optional
functionality that we consider harmful because it results, for
example, in unpredictable number parsing, inconsistent error message
output, unsafe character encoding, and the like. But maybe that's
a matter of opinion.
Thanks for following up on this to this point!
Ingo
$ make setlocale
cc -O2 -pipe-o setlocale setlocale.c
$ ./setlocale
First part of test:
setlocale(LC_CTYPE, foo) = foo
setlocale(LC_COLLATE, bar) = bar
setlocale(LC_ALL, NULL) = bar/foo/C/C/C/C
Second part of test:
setlocale(LC_CTYPE, baz) = baz
setlocale(LC_ALL, NULL) = bar/baz/C/C/C/C
setlocale(LC_ALL, save) = bar/foo/C/C/C/C
setlocale(LC_CTYPE, NULL) = foo
$ cat setlocale.c
#include
#include
#include
#include
#include
int
main(void)
{
char *retval, *save;
puts("First part of test:");
if ((retval = setlocale(LC_CTYPE, "foo")) == NULL)
errx(1, "setlocale(LC_CTYPE, foo) failed");
printf("setlocale(LC_CTYPE, foo) = %s\n", retval);
if ((retval = setlocale(LC_COLLATE, "bar")) == NULL)
errx(1, "setlocale(LC_COLLATE, bar) failed");
printf("setlocale(LC_COLLATE, bar) = %s\n", retval);
if ((retval = setlocale(LC_ALL, NULL)) == NULL)
errx(1, "setlocale(LC_ALL, NULL) failed");
printf("setlocale(LC_ALL, NULL) = %s\n", retval);
puts("\nSecond part of test:");
if ((save = strdup(retval)) == NULL)
err(1, NULL);
if ((retval = setlocale(LC_CTYPE, "baz")) == NULL)
errx(1, "setlocale(LC_CTYPE, baz) failed");
printf("setlocale(LC_CTYPE, baz) = %s\n", retval);
if ((retval = setlocale(LC_ALL, NULL)) == NULL)
errx(1, "setlocale(LC_ALL, NULL) failed");
printf("setlocale(LC_ALL, NULL) = %s\n", retval);
if ((retval = setlocale(LC_ALL, save)) == NULL)
errx(1, "setlocale(LC_ALL, save) failed");
printf("setlocale(LC_ALL, save) = %s\n", retval);
if ((retval = setlocale(LC_CTYPE, NULL)) == NULL)
errx(1, "setlocale(LC_CTYPE, NULL) failed");
printf("setlocale(LC_CTYPE, NULL) = %s\n", retval);
free(save);
return 0;
}
Re: setlocale() bugs
On 03/29/2018 10:56 AM, Ingo Schwarze wrote:
Hi Karl,
Karl Williamson wrote on Mon, Mar 19, 2018 at 11:51:31AM -0600:
I still believe that in my program the setlocale() returning C for
LC_ALL is a bug. LC_CTYPE should have successfully been set to Romanian
UTF-8, and so LC_ALL isn't C. Instead, it is a combination of C for all
the other categories, and UTF-8 for LC_CTYPE. A return of just "C"
doesn't reflect that complexity. There is a footnote in the ANSI/ISO
9899-1990 C standard that the returned string must support that
heterogeneity, and that the return value be able to be used in a future
setlocale to get back to the original state. Your setlocale violates
the standard therefore, and harms your portability goal.
Thanks again for reporting this bug, i fixed it with the commit below.
(And to be
consistent, LC_ALL should have been the heterogenous composition of all
the locale strings that the program sets, even if they just boil down to
C or UTF-8. Programs that run on other OS's are expecting this, and
again your portability goal is compromised)
I fear i still don't understand what you mean here.
Is that part also fixed with my commit?
If not, or if you are not sure (because you lack a test system),
can you state as precisely as possibly which call, that currently
has which effect and returns which value should have which other
effect and return which other value instead?
Your setlocale is a stub, but it should act consistently.
If I set LC_CTYPE to foo, and LC_COLLATE to bar, and then request
setlocale(LC_CTYPE, NULL), it returns 'foo', and
setlocale(LC_COLLATE, NULL), it returns 'bar', even though that's not
really true. I understand why you do that, but I claim that you should
maintain consistency when asking for
setlocale(LC_ALL, NULL)
Currently it just says 'C', but code from other systems would be
expecting it to act as if the previous calls actually took effect.
In Linux it would return
LC_CTYPE=foo;LC_COLLATE=bar;LC_NUMERIC=C...
And I think you should do something similar, so that what gets returned
by LC_ALL reflects what previous individual setlocale's have done.
Right now, if you set LC_CTYPE to foo, then call
const char * save=setlocale(LC_ALL, NULL);
to save things, then change LC_CTYPE to baz, then call
setlocale(LC_ALL, save)
printf("%s\n", setlocale(LC_CTYPE,NULL)
I don't believe it will be foo because your LC_ALL returned a value that
didn't contain 'foo'.
A stub needs to sufficiently emulate the real thing so that you don't
get inconsistent results.
If this isn't clear, let me know.
I urge you to update your man page. If it had set out what you've
stated in your replies, it would have saved our project a bunch of hours
of work.
Sorry for that. We do regard bugs in manuals as about as important
as bugs in the implementation, but just as with code, it can't be
helped that sometimes, bugs and omissions happen anyway.
Yours,
Ingo
CVSROOT:/cvs
Module name:src
Changes by: schwa...@cvs.openbsd.org2018/03/29 10:34:25
Modified files:
lib/libc/locale: setlocale.c
regress/lib/libc/locale/setlocale: setlocale.c
Log message:
Fix three bugs in setlocale(3):
1. setlocale(LC_ALL, "A"); setlocale(LC_CTYPE, "T"); setlocale(LC_ALL, NULL);
must return "A/T/A/A/A/A", not "A". Fix this by always initializing the
LC_ALL entry of newgl to "" in dupgl(). Reported by Karl Williamson
on bugs@, thanks!
2. Do not leak newgl when strdup(3) fails in setlocale(3).
3. For setlocale(LC_ALL, "C/C/fr_FR.UTF-8/C/C/C"); correctly set
_GlobalRuneLocale; i found 2. and 3. while looking at the code.
Feedback on a buggy earlier version and OK martijn@.
Index: lib/libc/locale/setlocale.c
===
RCS file: /cvs/src/lib/libc/locale/setlocale.c,v
retrieving revision 1.27
diff -u -p -r1.27 setlocale.c
--- lib/libc/locale/setlocale.c 5 Sep 2017 03:16:13 - 1.27
+++ lib/libc/locale/setlocale.c 29 Mar 2018 16:32:53 -
@@ -42,8 +42,8 @@ dupgl(char **oldgl)
if ((newgl = calloc(_LC_LAST, sizeof(*newgl))) == NULL)
return NULL;
for (ic = LC_ALL; ic < _LC_LAST; ic++) {
- if ((newgl[ic] = strdup(oldgl != NULL ?
- oldgl[ic] : ic == LC_ALL ? "" : "C")) == NULL) {
+ if ((newgl[ic] = strdup(ic == LC_ALL ? "" :
+ oldgl == NULL ? "C" : oldgl[ic])) == NULL) {
freegl(newgl);
return NULL;
}
@@ -92,8 +92,10 @@ setlocale(int category, const char *locn
if (category == LC_ALL && strchr(locname, '/') != NULL) {
/* One value for each category. */
- if ((firstname = strdup(locname)) == NULL)
+ if ((firstname = strdup(locname)) == NULL) {
+ freegl(newgl);
return NULL;
+ }
Re: amd64 current snapshot core dump error in thunar segmentation fault in seamonkey and ws error touchpad
sudhir kumar lal wrote: > 2. Thunar crashes a lot when i am selecting a file and pressing Shift+Delete > to delete the file then 4 out of 5 times thunar will crash and i will get an > error : > Bus error (core dumped) > And in the present working directory a file called thunar.core will appear. > It generally is a 10MB file but i cannot open it in vim so i always delete > it. Yeah I could reproduce that one, albeit less frequently than what you describe. Here is one stacktrace I got, I've seen others but the pattern is the same, Thread 3 is in futex, thread 2 in another syscall (poll or here mmap) and thread 1 is in glib2. Still looking into it but nothing obvious is popping up right now. Thread 3 (process 254614): #0 futex () at -:3 #1 0x0fe435fc345f in _libc_pthread_mutex_unlock (mutexp=Variable "mutexp" is not available. ) at synch.h:25 #2 0x0fe4824832eb in g_mutex_unlock (mutex=0xfe44c9e1c00) at gthread-posix.c:233 #3 0x0fe4824361a9 in g_source_attach (source=Variable "source" is not available. ) at gmain.c:1226 #4 0x0fe422688f72 in exo_job_scheduler_job_func () from /usr/local/lib/libexo-1.so.0.2 #5 0x0fe43b09bf0f in io_job_thread (task=Variable "task" is not available. ) at gioscheduler.c:85 #6 0x0fe43b0c63d1 in g_task_thread_pool_thread (thread_data=0xfe4084b31d0, pool_data=Variable "pool_data" is not available. ) at gtask.c:1328 #7 0x0fe482463de3 in g_thread_pool_thread_proxy (data=0xfe494ece080) at gthreadpool.c:307 #8 0x0fe482462ccc in g_thread_proxy (data=0xfe3e7add9e0) at gthread.c:784 #9 0x0fe43e89fc0e in _rthread_start (v=Variable "v" is not available. ) at /usr/src/lib/librthread/rthread.c:96 #10 0x0fe435ff5c7b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 #11 0x in ?? () Current language: auto; currently asm Thread 2 (process 300300): #0 _thread_sys___syscall () at -:3 #1 0x0fe43603b695 in _libc_mmap (addr=Variable "addr" is not available. ) at /usr/src/lib/libc/sys/mmap.c:47 #2 0x0fe43e8a0481 in _rthread_alloc_stack (thread=Variable "thread" is not available. ) at /usr/src/lib/librthread/rthread_stack.c:94 #3 0x0fe43e89fad1 in pthread_create (threadp=0xfe3b28f13a0, attr=0x7f7d6f50, start_routine=0xfe482462c70 , arg=Variable "arg" is not available. ) at /usr/src/lib/librthread/rthread.c:380 #4 0x0fe482483fd4 in g_system_thread_new (thread_func=0xfe482462c70 , stack_size=Variable "stack_size" is not available. ) at gthread-posix.c:1170 #5 0x0fe482462f0a in g_thread_try_new (name=0xfe4825b36ab "pool", func=0xfe482463cc0 , data=0xfe494ece080, error=0x7f7d6ff0) at gthread.c:874 #6 0x0fe482463377 in g_thread_pool_start_thread (pool=0xfe494ece080, error=0x7f7d6ff0) at gthreadpool.c:407 #7 0x0fe482463422 in g_thread_pool_push (pool=0xfe494ece080, data=0xfe4084b3370, error=0x0) at gthreadpool.c:563 #8 0x0fe43b0c55a7 in g_task_run_in_thread (task=0xfe4084b3370, task_func=0xfe43b09bee0 ) at gtask.c:1442 #9 0x0fe43b09be2b in g_io_scheduler_push_job (job_func=0xfe422688e50 , user_data=Variable "user_data" is not available. ) at gioscheduler.c:146 #10 0x0fe422688e3a in exo_job_launch () from /usr/local/lib/libexo-1.so.0.2 #11 0x0fe1ae2560b1 in thunar_navigator_open_new_tab () from /usr/local/bin/thunar #12 0x0fe1ae223787 in thunar_file_compare_by_name () from /usr/local/bin/thunar #13 0x0fe1ae25cd4d in thunar_standard_view_selection_changed () from /usr/local/bin/thunar #14 0x0fe3e6b1c5c3 in g_closure_invoke (closure=0xfe494ece1a0, return_value=0x0, n_param_values=1, param_values=0x7f7d73f0, invocation_hint=Variable "invocation_hint" is not available. ) at gclosure.c:804 #15 0x0fe3e6b323b6 in signal_emit_unlocked_R () at gsignal.c:3635 #16 0x0fe3e6b33172 in g_signal_emit_valist (instance=Variable "instance" is not available. ) at gsignal.c:3391 #17 0x0fe3e6b3382f in g_signal_emit (instance=Variable "instance" is not available. ) at gsignal.c:3447 #18 0x0fe422689436 in exo_job_async_ready () from /usr/local/lib/libexo-1.so.0.2 #19 0x0fe482438ea8 in g_main_context_dispatch (context=Variable "context" is not available. ) at gmain.c:3165 #20 0x0fe482439295 in g_main_context_iterate () at gmain.c:3891 #21 0x0fe4824395ff in g_main_loop_run (loop=0xfe47d76e400) at gmain.c:4087 #22 0x0fe46d31655f in IA__gtk_main () at gtkmain.c:1270 #23 0x0fe1ae20904b in _thunar_marshal_VOID__OBJECT_OBJECT () from /usr/local/bin/thunar #24 0x0fe1ae205a96 in ?? () from /usr/local/bin/thunar #25 0x in ?? () Thread 1 (process 293779): #0 dl_calculate (before=0xfe49c93cb80, after=0x0, cbs=0xfe43b30, udata=0xfe3e6a110b8) at dep-list.c:101 #1 0x0fe43b1578fd in _kh_dir_diff (sub=0xfe44be6cf80) at kqueue-helper.c:176 #2 0x0fe43b15781e in g_kqueue_file_monitor_callback (fd=10, condition=Variable "condition" is not available. ) at
Re: Add "dummy" man page for the X dummy driver? ("void" kbd driver has a man page.)
On Thu, Mar 29, 2018 at 11:17:33AM -0400, Tinker wrote: > Hi, > > The dummy X graphics driver may be slightly outdated but it exists and > works. > > The keyboard and mouse driver void(4) does have a man page, and is > referenced in x.org(5)'s SEE ALSO section. > > Shouldn't "dummy" have a man page and be referenced in x.org(5)'s SEE > ALSO section also? > isn;t that a question for the X project? jmc > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-dummy/ > > https://marc.info/?t=15187399242=1=2 > https://marc.info/?t=15223071333=1=2 > https://marc.info/?l=openbsd-misc=152233592922216=2 > > http://man.openbsd.org/void.4 > > http://man.openbsd.org/xorg.conf.5#SEE_ALSO > > Tinker >
