Guard fopen() results with a false-check before fwrite/fprintf/fclose

2026-08-17T19:53:08+00:00

On PHP 7.4, calling fwrite()/fprintf()/fclose() with a false handle (a failed fopen(), e.g. from a bad path, missing directory, or permissions issue) just emits a warning and no-ops. On PHP 8.0+, these functions require a resource argument and throw an uncaught TypeError instead, turning what used to be a silent degradation into a fatal crash of the whole request. This patch wraps every fopen()-then-write call site in the codebase (18 files) with an `if ($handle !== false) { ... }` check, matching the existing pattern used elsewhere in the codebase. Where the same $fpvar handle is threaded through shared helper functions (enter_ban_list/banlist/whitelist, duplicated across remove_variables_processing.php, remove_variables_processing_default.php, modify_structure_learning.php and tier_description_processing_gom.php), the guard was added inside those functions too for consistency, even though the call sites are currently dead/commented-out in three of the four files — so the same landmine doesn't reappear if that code is ever re-enabled. Verified empirically against PHP 8.3.28: fopen() on an unwritable path followed by fwrite() on the resulting `false` throws TypeError: fwrite(): Argument #1 ($stream) must be of type resource, false given without the guard; with the guard, the call is skipped instead of crashing. The normal (successful fopen) path was also re-run through mat_structure.php's structure_change() and still produces identical output to before the change. Reviewed by: Frederick M Muriithi

Moving final GENENET8 version to master

2021-02-24T21:19:03+00:00

GENENET8 update

2021-02-24T20:36:59+00:00

Jan 28 2019 update

2019-01-28T22:31:54+00:00

BNW/sourcecodes/remove_variables_processing.php, branch main

Guard fopen() results with a false-check before fwrite/fprintf/fclose

Moving final GENENET8 version to master

GENENET8 update

Jan 28 2019 update