Re: [PATCH 0/1] libgfortran: Fix compilation of gf_vsnprintf
> Gentle ping. If this looks good, can someone commit to main (I don't have > commit privileges). This is also something that could be considered for > stable, since it's been around for many years. Thanks for the patch. Pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3bd3ca05b519b99b5ea570c10fd80737cd4c6c49 FX
Re: [PATCH 0/1] libgfortran: Fix compilation of gf_vsnprintf
Gentle ping. If this looks good, can someone commit to main (I don't have commit privileges). This is also something that could be considered for stable, since it's been around for many years. -Ian From: McInerney, Ian S Sent: Thursday, April 4, 2024 4:16 PM To: fort...@gcc.gnu.org ; gcc-patches@gcc.gnu.org Cc: McInerney, Ian S Subject: [PATCH 0/1] libgfortran: Fix compilation of gf_vsnprintf The fallback function (gf_vsnprintf) to provide a vsnprintf function if the system library doesn't have one would not compile due to the variable name for the string's destination buffer not being updated after the refactor in 2018 in edaaef601d0d6d263fba87b42d6d04c99dd23dba. This updates the internal logic of gf_vsnprintf to now use the str variable defined in the function signature. I am not actually sure what configurations are using this fallback, since it was added in 2018 and no patches have been made to fix this compilation error. Testing this also isn't straightforward, and I had to do a bit of a hack to get it to use the codepath to show the compilation error: 1) Configure and build as normal to generate the config.h header 2) Modify config.h directly to undefine HAVE_VSNPRINTF 3) Directly call the libgfortran compilation step Ian McInerney (1): libgfortran: Fix compilation of gf_vsnprintf libgfortran/runtime/error.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) base-commit: b7bd2ec73d66f7487bc8842b24daecaa802a72e6 -- 2.43.0
[PATCH 0/1] libgfortran: Fix compilation of gf_vsnprintf
The fallback function (gf_vsnprintf) to provide a vsnprintf function if the system library doesn't have one would not compile due to the variable name for the string's destination buffer not being updated after the refactor in 2018 in edaaef601d0d6d263fba87b42d6d04c99dd23dba. This updates the internal logic of gf_vsnprintf to now use the str variable defined in the function signature. I am not actually sure what configurations are using this fallback, since it was added in 2018 and no patches have been made to fix this compilation error. Testing this also isn't straightforward, and I had to do a bit of a hack to get it to use the codepath to show the compilation error: 1) Configure and build as normal to generate the config.h header 2) Modify config.h directly to undefine HAVE_VSNPRINTF 3) Directly call the libgfortran compilation step Ian McInerney (1): libgfortran: Fix compilation of gf_vsnprintf libgfortran/runtime/error.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) base-commit: b7bd2ec73d66f7487bc8842b24daecaa802a72e6 -- 2.43.0
