BNW/sourcecodes/mat_structure.php, branch main

Guard arithmetic on file/shell-output-derived values against non-numeric strings

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

PHP 8 throws a fatal TypeError for arithmetic (+ - * /) on a non-numeric string ("Unsupported operand types"); PHP 7.4 only warned and treated it as 0. Several files perform arithmetic directly on values parsed from intermediate state files (nnode.txt, nrows.txt, structure_input*.txt) or from `dot -Tplain` output, with no is_numeric() check — safe as long as those files are well-formed, but a crash risk if a file is missing/empty/truncated or a `dot` output line doesn't parse as expected. Affected: runtime_check.php ($node, $nrows), remove_variables.php and create_tiers_gom_part1.php ($maxplist=$node-1), mat_structure.php (matrix cell multiplication), and the four network_layout_{evd,inv}[,_2].php files ($r_index=$node+N and the dot-output-derived $cell arithmetic in the _2 variants). Fix pattern: coalesce to 0 via `is_numeric($x) ? $x : 0` before the arithmetic, matching PHP 7.4's original fallback-to-0 behavior instead of crashing. Verified empirically against PHP 8.3.28 with runtime_check.php and mat_structure.php: previously, a missing/empty source file caused TypeError: Unsupported operand types: string - int (or string * int) after the fix, the same missing-file scenario produces only the pre-existing "undefined array key" warnings (same as PHP 7.4) and the function completes and returns a value instead of crashing. Reviewed by: Frederick M Muriithi

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

Add files via upload

2017-09-14T20:57:50+00:00