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

go to bug id or search bugs for

Bug #60391 fputcsv() returns NULL if first argument is not resource
Submitted: 2011-11-26 08:00 UTC Modified: 2011-12-03 19:21 UTC
From: ninzya at inbox dot lv Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: 5.4.0RC2 OS: Windows 7
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ninzya at inbox dot lv
New email:
PHP Version: OS:

 

 [2011-11-26 08:00 UTC] ninzya at inbox dot lv 
Description:
------------
PHP documentation on fputcsv() [http://www.php.net/manual/en/function.fputcsv.php] 
says (quote):

"Returns the length of the written string or FALSE on failure".

This is not true if fputcsv() gets a non-resource variable as it's first argument. 
In this case it returns NULL.

Test script:
---------------
$arg =true;
//$arg =false;
//$arg =1;
//$arg =null;
//$arg =array();
//$arg =new stdClass;

var_dump( fputcsv( $arg, array( 'x', 'y', 'z')));

Expected result:
----------------
bool(false)

Actual result:
--------------
NULL

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-12-03 03:08 UTC] me at ktamura dot com 
NULL is returned when zend_parse_parameters returns FAILURE, meaning the types of 
the parameters didn't match the function signature. This is the behavior for many 
other buildin functions such as flock, realpath, etc. I don't think this is a bug.
 [2011-12-03 16:24 UTC] ninzya at inbox dot lv 
Documentation does not cover the case you have described: "Returns the length of 
the written string or FALSE on failure" does not mean "NULL is returned when 
zend_parse_parameters returns FAILURE, meaning the types of 
the parameters didn't match the function signature".

So from my point of view the problem is either in the code or in the 
documentation.
 [2011-12-03 19:21 UTC] salathe@php.net 
See the following note on the "Internal (built-in) functions" page [1].

"Note: If the parameters given to a function are not what it expects, such as 
passing an array where a string is expected, the return value of the function is 
undefined. In this case it will likely return NULL but this is just a 
convention, and cannot be relied upon."

By convention, we do not mention this "undefined" behaviour (NULL for the vast 
majority of functions) on bad arguments in each and every function's "Return 
Values" section.  See also, GIGO [2].

[1] http://php.net/manual/en/functions.internal.php
[2] http://en.wikipedia.org/wiki/Garbage_in,_garbage_out
 [2011-12-03 19:21 UTC] salathe@php.net
-Status: Open +Status: Bogus
 [2011-12-03 22:23 UTC] ninzya at inbox dot lv 
Oh, that's cute. I've been developing apps with PHP for 5+ years and now this is 
first hearing of such "built in" feature for me. Really nice. Good docs. Very 
intuitive.

I think I'm starting to think about giving up PHP and move to something more 
life-ready (read - "enterprise-ready").
 [2011-12-04 16:14 UTC] anon at anon dot anon 
>I think I'm starting to think about giving up PHP and move to something more 
life-ready (read - "enterprise-ready").

Ditto. This is extremely poor behavior for a programming language to have, but it's just another day for PHP. :(
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Nov 04 08:00:01 2025 UTC