On Tue, 16 Sept 2025 at 04:08, Collin Funk <[email protected]> wrote:
> Worth mentioning that iswblank on some systems behaves like isblank > (only SPACE and TAB). This caused some problems in Coreutils [1]. > That would seem to me to be a case for including a replacement version of iswblank that can be deployed on affected systems. Then it would become a build-time option much like choosing the system-provided or included versions of libreadline or libintl. More generally, I find it tedious to read code that has lots of functions that replicate standard C functions under different names, just because somewhere there exists some broken compiler or broken libc. It's a (small) waste of each new developers' time to have to check definitions just to be sure that they don't differ from the standard functions in some minor way, and then memorising a list of equivalences. Although the C standard prohibits re-using the names of standard functions, it also mandates that those functions should operate as advertised. Meanwhile « # define standard_function_name replacement_version_that_works » has a minimal chance of messing up, and so I think this would be an acceptable trade-off to keep code more readable. There is of course a small chance that some platform that needs such a replacement function also has a compiler that cannot handle #define overriding its broken version, but are there enough such platforms & compilers to warrant continued redundant extra names for standard functions? At what point is it acceptable to say “sorry, Bash no longer supports your compiler and/or libraries; please update them or switch to gcc & glibc”? If anyone knows of a platform that *still* has a broken iswblank or any other standard C function, and/or has a compiler that barfs when you #define a reserved identifier, please email me privately with the details, and I will summarise the results. -Martin
