Change Details

A dummy application which prints errno as its first action reveals that errno is non-zero in at least two cases: the application is linked with libthr.so, because the thr_wake(-1) call in _thr_rtld_init() sets errno = ESRCH, and second, the application is statically linked with libthr.a, since libc's uexterr_ctr() runs after the exterrctl(EXTERRCTL_ENABLE) call in init_main_thread(), so the second exterrctl() call returns EBUSY (since it does not specify EXTERRCTLF_FORCE. Just zero errno immediately before program startup. Or, maybe we should be more careful and clear errno in the precise spots where errors can occur? Reported by: Greg Becker

``` A dummy application which prints errno as its first action reveals that errno is non-zero in at least two cases: the application is linked with libthr.so, because the thr_wake(-1) call in _thr_rtld_init() sets errno = ESRCH, and second, the application is statically linked with libthr.a, since libc's uexterr_ctr() runs after the exterrctl(EXTERRCTL_ENABLE) call in init_main_thread(), so the second exterrctl() call returns EBUSY (since it does not specify EXTERRCTLF_FORCE. Just zero errno immediately before program startup. Or, maybe we should be more careful and clear errno in the precise spots where errors can occur? ``` Reported by: Greg Becker

``` A dummy application which prints errno as its first action reveals that errno is non-zero in at least two cases: the application is linked with libthr.so, because the thr_wake(-1) call in _thr_rtld_init() sets errno = ESRCH, and second, the application is statically linked with libthr.a, since libc's uexterr_ctr() runs after the exterrctl(EXTERRCTL_ENABLE) call in init_main_thread(), so the second exterrctl() call returns EBUSY (since it does not specify EXTERRCTLF_FORCE. Just zero errno immediately before program startup. Or, maybe we should be more careful and clear errno in the precise spots where errors can occur? ``` Reported by: Greg Becker