Bug #71219 [Opn->Fbk]: php's configure script incorrectly checks for ttyname_r availability

From: Date: Sat, 26 Dec 2015 05:11:48 +0000
Subject: Bug #71219 [Opn->Fbk]: php's configure script incorrectly checks for ttyname_r availability
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-198231@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=71219&edit=1 ID: 71219 Updated by: laruence@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: Feedback Type: Bug Package: *Compile Issues Operating System: Linux (Gentoo Hardened) PHP Version: 5.6.16 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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

« previous php.bugs (#198231) next »