|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60779 Incorrect return value for getprotobyname
Submitted: 2012-01-17 14:19 UTC Modified: 2012-01-20 12:01 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: wojtos at gmail dot com Assigned:
Status: Duplicate Package: *Network Functions
PHP Version: Irrelevant OS: Debian Squeeze
Private report: No CVE-ID: None
 [2012-01-17 14:19 UTC] wojtos at gmail dot com
From manual page:

Return for unrecognized protocol is 0 instead of -1.

PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 13:13:26) 

Test script:
$protocol = 'BLA';
$get_prot = getprotobyname($protocol);
if ($get_prot == -1) {
    echo 'Invalid Protocol';
} else {
    echo 'Protocol #' . $get_prot;

Expected result:
Invalid Protocol

Actual result:
Protocol #0


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-01-17 15:46 UTC] phpmpan at mpan dot pl
This is not a bug in `getprotobyname`. It's a bug in documentation for the function. `getprotobyname` returns `FALSE`, not 0 in case of an error. I will fill a report for that in a moment. You can close this one.
 [2012-01-17 16:25 UTC] phpmpan at mpan dot pl
Or you can't...

Are you sure that you're receiving 0, not `FALSE`? If yes, than I'm NOT confirming this behaviour with 5.3.9, 5.3-dev, 5.4-dev or trunk-dev (on Arch64). In all four versions `getprotobyname` returns `FALSE`.

Also returning 0 seems very strange. PHP just forwards the call to `getprotobyname` from netdb. In case of an error or if a protocol is not found, this function should return `NULL`. PHP checks if the call has returned `NULL` and, if it did, returns `FALSE`. Therefore if you're receiving 0, this would indicate a bug in the host environment, not in PHP itself.

-------- BEGIN CODE --------
// ext/standard/basic_functions.c from SVN
// ...
ent = getprotobyname(name);

if (ent == NULL) {
// ...
--------- END CODE ---------
 [2012-01-18 08:21 UTC] wojtos at gmail dot com
Thank You for your reply. Indeed I checked and it does return FALSE. The bug or rather misinformation lies in the documentation where it states "Returns the protocol number or -1 if the protocol is not found.". When in the test script I checked for === FALSE it worked as expected.
 [2012-01-20 02:22 UTC]
dup to #60781
 [2012-01-20 02:22 UTC]
-Status: Open +Status: Duplicate
 [2012-01-20 12:01 UTC] wojtos at gmail dot com
That is a duplicate of this and not the other way around! (id and time).
Anyhow. Glad it's fixed.
 [2012-01-20 20:06 UTC] phpmpan at mpan dot pl
There is nothing negative in having your post marked as DUP in this case. I believe it's purely organisational thing and laruence's intention wasn't telling you that you did something wrong. If one of the two reports is closed after fixing an issue, the second one needs to be set to DUP. This is not a contest on who will get more successful reports ;), so it doesn't matter which one it is. The goal was accomplished: PHP is better than it was before.

Don't get discouraged and keep helping to improve PHP.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 16 18:01:30 2024 UTC