php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #60779 Incorrect return value for getprotobyname
Submitted: 2012-01-17 14:19 UTC Modified: 2012-01-20 12:01 UTC
Votes:2
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
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
47 - 1 = ?
Subscribe to this entry?

 
 [2012-01-17 14:19 UTC] wojtos at gmail dot com 
Description:
------------
---
From manual page: http://www.php.net/function.getprotobyname#refsect1-function.getprotobyname-returnvalues
---

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:
---------------
<?php
$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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

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) {
    RETURN_FALSE;
}
// ...
--------- 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] laruence@php.net 
dup to #60781
 [2012-01-20 02:22 UTC] laruence@php.net
-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: Thu Apr 25 22:01:29 2024 UTC