[echoix]

Follow-up from #7660

This PR applies the same logic as the other PR, where how sscanf can also return EOF "if input failure occurs before the first receiving argument was assigned". (See https://en.cppreference.com/c/io/fscanf).

Here, the little touch that is different for raster/r.out.vtk/writeascii.c and raster3d/r3.out.vtk/writeVTKData.c, is that I assume that if there's the EOF case, or any invalid case for the null_value, we would still want the null value to be 0. I think that's the design intention behind the code.

This was assisted by AI (Copilot-generated fix suggestions for code scanning alerts), but we can reason through it and I applied some myself in order to batch them in one single PR.

This should fix:

• https://github.com/OSGeo/grass/security/code-scanning/525
• https://github.com/OSGeo/grass/security/code-scanning/526
• https://github.com/OSGeo/grass/security/code-scanning/527
• https://github.com/OSGeo/grass/security/code-scanning/528
• https://github.com/OSGeo/grass/security/code-scanning/531
• https://github.com/OSGeo/grass/security/code-scanning/532
• https://github.com/OSGeo/grass/security/code-scanning/533

[echoix]

@petrasovaa I added the fix to of https://github.com/OSGeo/grass/security/code-scanning/532, does it make sense in this situation for you too?

[echoix]

There should be no other CodeQL alerts of this type after merging this

[wenzeslaus]

I think the intention is: "on failure to read use fallback to the hardcoded value", so yes, any failure should trigger that, and so the change is correct.

My understanding is that there is no change in behavior because with one formatting specifies, the function will still only read first one item even if there is multiple valid values. Perhaps obvious, but it crossed my mind, so I examined also that angle.