fputcsv() flagged when writing to stream

[paulschreiber]

Bug Description

The below code creates a CSV for download. PHPCS flags this as an error. I'm writing to a stream, not the filesystem.

Minimal Code Snippet

$output_stream = fopen( 'php://output', 'w' );

foreach ( $list as $row ) {
    fputcsv( $output_stream, $row );
}

Error Code

  88 | ERROR   | Filesystem writes are forbidden, you should not be using
     |         | fputcsv() (WordPress.VIP.FileSystemWritesDisallow)

Environment

Question	Answer
PHP version	7.1.23
PHP_CodeSniffer version	3.4.1
VIPCS version	0.2.5

[GaryJones]

VIPCS version | 0.2.5

Does this still happen with VIPCS 0.4.0 (latest published version)?

How about master?

[paulschreiber]

• Aside: version 0.4.0 of VIPCS conflicts with WPCS 2.1.0.
• Problem still occurs with VIPCS 0.4.0, WPCS 1.2.1, PHPCS 3.4.1,

[GaryJones]

How about master?

[paulschreiber]

@GaryJones Is there a specific commit or PR you think addresses this or a related problem? Or are you just enjoying having me randomly regress things?

Yes, the problem still occurs with master (97fa945).

[GaryJones]

Thank you.

Background notes:

• https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/blob/develop/WordPress/Sniffs/WP/AlternativeFunctionsSniff.php (WPCS 2.*) contains some replacement WP function suggestions, which include taking into account streams, but fputcsv is not on there, since there is no WP_Filesystem suggestion for it.
• We need to re-check exactly what the restriction is for fputcsv() on VIP (all instances / not for streams / not for custom streams, etc.) and adjust the sniff (or likely make a new sniff) accordingly.

[rebeccahum]

Due to the nature of static analysis, I think that that example would still flagged it because of $output_stream being a variable.

@jrfnl What are your thoughts for this one?

[jrfnl]

@rebeccahum I agree.

Just based on the call to fputcsv(), there is no way to know whether the output will be written to a file or a stream.

With the code snippet above, the sniff could walk back to find how $output_stream is declared and analyse that, but in reality, most code isn't this clean cut and the $handle ($output_stream variable) may be passed into a function doing the actual writes, as a function parameter in which case there is no way to know what was passed in.

We know it will be a resource handle, but that's it. Presuming it is a resource handle to php://output would be a huge jump and would leave any code which does actually attempt to write to a file undetected, which I think is a worse outcome.