https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80047
--- Comment #9 from Eric Gallager <egallager at gcc dot gnu.org> --- (In reply to CVS Commits from comment #8) > The master branch has been updated by Xi Ruoyao <xry...@gcc.gnu.org>: > > https://gcc.gnu.org/g:04c5a91d068c4ca2f09c2bc206fce00db9d1790b > > commit r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b > Author: Xi Ruoyao <xry...@mengyan1223.wang> > Date: Tue Nov 9 21:40:04 2021 +0800 > > fixincludes: simplify handling for access() failure [PR21283, PR80047] > > POSIX says: > > On some implementations, if buf is a null pointer, getcwd() may > obtain > size bytes of memory using malloc(). In this case, the pointer > returned > by getcwd() may be used as the argument in a subsequent call to > free(). > Invoking getcwd() with buf as a null pointer is not recommended in > conforming applications. > > This produces an error building GCC with --enable-werror-always: > > ../../../fixincludes/fixincl.c: In function âprocessâ: > ../../../fixincludes/fixincl.c:1356:7: error: argument 1 is null but > the corresponding size argument 2 value is 4096 [-Werror=nonnull] > > It's suggested by POSIX to call getcwd() with progressively larger > buffers until it does not give an [ERANGE] error. However, it's highly > unlikely that this error-handling route is ever used. > > So we can simplify it instead of writting too much code. We give up to > use getcwd(), because `make` will output a `Leaving directory ...` > message > containing the path to cwd when we call abort(). > > fixincludes/ChangeLog: > > PR other/21823 > PR bootstrap/80047 > * fixincl.c (process): Simplify the handling for highly > unlikely access() failure, to avoid using non-standard > extensions. So... ok to close as FIXED then? Or leave open for backports?
