Edit report at https://bugs.php.net/bug.php?id=71219&edit=1
ID: 71219
Updated by: nikic@php.net
Reported by: atoth at atoth dot sote dot hu
Summary: php's configure script incorrectly checks for
ttyname_r availability
-Status: Open
+Status: Closed
Type: Bug
Package: *Compile Issues
Operating System: Linux (Gentoo Hardened)
PHP Version: 5.6.16
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of nikic
Revision: http://git.php.net/?p=php-src.git;a=commit;h=14d674442ef86ad4e862228a1ff5ecd322ae7759
Log: Fixed bug #71219
Previous Comments:
------------------------------------------------------------------------
[2015-12-26 16:46:36] atoth at atoth dot sote dot hu
Your logic is right, however the test still returns false.
"checking for working ttyname_r() implementation... no, posix_ttyname() will be
thread-unsafe"
configure.log show this:
"configure:79083: checking for working ttyname_r() implementation
configure:79104: x86_64-pc-linux-gnu-gcc -o conftest -I/usr/include -O2 -march=native -pipe -pthread
-D_REENTRANT -L/usr/lib64 -Wl,-O1 -Wl,--as-needed conftest.c -liodbc -lmcrypt -lltdl -lonig
-lstdc++ -lcrypto -lssl -lcrypto -lcrypt -lpam -lgmp -lt1 -lX11 -lXpm -lpng -lz -ljpeg -lvpx
-lcrypto -lssl -lcrypto -lenchant -ldb-5.1 -lgdbm -lcurl -lbz2 -lz -lpcre -lcrypto -lssl -lcrypto
-lrt -lm -ldl -lnsl -lxml2 -lz -lm -ldl -lcurl -lnghttp2 -lidn -lrtmp -lz -lgmp -lgnutls -lhogweed
-lnettle -lssh2 -lssh2 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lz -lxml2 -lz -lm
-ldl -lfreetype -licui18n -licuuc -licudata -licuio -liodbc -liodbcinst -ldl -lodbc >&5
configure:79104: $? = 0
configure:79104: ./conftest
configure:79104: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
--
| #define HAVE_GETPWUID_R 1
| #define HAVE_GETGRGID_R 1
| /* end confdefs.h. */
|
| #include <unistd.h>
|
| int main(int argc, char *argv[])
| {
| char buf[64];
|
| return ttyname_r(0, buf, 64) ? 1 : 0;
| }
|
configure:79114: result: no, posix_ttyname() will be thread-unsafe"
I modified the check to output the return value, which was turned out to be: 25.
Errno #25 means: ENOTTY.
I modified the test program like this:
"
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
int main(int argc, char *argv[])
{
char buf[64];
int retval;
retval = ttyname_r(0, buf, 64);
printf("\nretval 0: %s, fd path 0: %s.\n", strerror(retval), buf);
retval = ttyname_r(1, buf, 64);
printf("retval 1: %s, fd path 1: %s.\n", strerror(retval), buf);
retval = ttyname_r(2, buf, 64);
printf("retval 2: %s, fd path 2: %s.\n", strerror(retval), buf);
return ttyname_r(0, buf, 64) ? 1 : 0;
}
"
This is the output I got:
checking for working ttyname_r() implementation...
retval 0: Inappropriate ioctl for device, fd path 0: H1gB?.
retval 1: Success, fd path 1: /dev/pts/2.
retval 2: Inappropriate ioctl for device, fd path 2: /dev/pts/2.
So my logic was wrong, but checking for fd 0 is inappropriate.
I guess ti would be better to check for fd 1, instead!
What's your opinion?
------------------------------------------------------------------------
[2015-12-26 05:11:46] laruence@php.net
I don't understant the problem here,
if ttyname_r() return 0; it mean success, then:
return ttyname_r(0, buf, 64) ? 1 : 0;
return 0, action-if-true is evaluated. seems correct to me.
------------------------------------------------------------------------
[2015-12-25 18:34:19] atoth at atoth dot sote dot hu
Description:
------------
While PHP's configure script checks for ttyname_r it uses this code snippet:
return ttyname_r(0, buf, 64) ? 1 : 0;
Although ttyname returns a pointer to the fd's null-terminated pathname or NULL on error -
ttyname_r behaves differently: it stores the pathname in a buffer and returns 0 on success or an
error number.
http://linux.die.net/man/3/ttyname_r
Therefore the above cited check will report a failure upon success.
Configure emits a messages about posix_ttyname being thread unsafe, despite ttyname_r is available.
I suggest to change the test logic by taking into account the return values. I attach a trivial
example patch below.
Please note, that this minor issue affects both 5.6* and the new 7.0* branches. I could not select
both branches for the report...
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=71219&edit=1