[PATCH] Restore lrealpath() fallback scenario
Hi all! Git commit e2bb55ec3b70cf45088bb73ba9ca990129328d60 (pr/108350) removes the fallback scenario for lrealpath() when none of the #ifdef's match (in which case the function is empty) In this situation, there is no return statement, and hence an uninitialized pointer value is returned. This is bad, as make_relative_prefix_1() uses this pointer and passes it to free(). This crashes in my hobby OS (https://github.com/zhmu/dogfood) as I do not implement any of the proper lrealpath() scenarios ;-) This is likely not an issue for any real use case, but I'm submitting this to prevent others from having to chase this. I've attached a simple patch that restores the fallback behaviour (return strdup(filename);) which it did prior to pr/108350. Regards, Rinkdiff -rubB gcc-15.1.0-base/libiberty/lrealpath.c gcc-15.1.0/libiberty/lrealpath.c --- gcc-15.1.0-base/libiberty/lrealpath.c 2025-04-25 10:18:04.0 +0200 +++ gcc-15.1.0/libiberty/lrealpath.c 2025-05-09 16:49:35.228340555 +0200 @@ -303,4 +303,7 @@ return res; } #endif // _WIN32 + + /* This system is a lost cause, just duplicate the filename. */ + return strdup (filename); }
Re: [PATCH] Restore lrealpath() fallback scenario
diff -rubB gcc-15.1.0-base/libiberty/lrealpath.c gcc-15.1.0/libiberty/lrealpath.c --- gcc-15.1.0-base/libiberty/lrealpath.c 2025-04-25 10:18:04.0 +0200 +++ gcc-15.1.0/libiberty/lrealpath.c 2025-05-09 16:49:35.228340555 +0200 @@ -303,4 +303,7 @@ return res; } #endif // _WIN32 + + /* This system is a lost cause, just duplicate the filename. */ + return strdup (filename); } > On 05/09/2025 5:04 PM CEST Rink Springer wrote: > > > Hi all! > > Git commit e2bb55ec3b70cf45088bb73ba9ca990129328d60 (pr/108350) removes the > fallback scenario for lrealpath() when none of the #ifdef's match (in which > case the function is empty) > In this situation, there is no return statement, and hence an uninitialized > pointer value is returned. This is bad, as make_relative_prefix_1() uses this > pointer and passes it to free(). > > This crashes in my hobby OS (https://github.com/zhmu/dogfood) as I do not > implement any of the proper lrealpath() scenarios ;-) This is likely not an > issue for any real use case, but I'm submitting this to prevent others from > having to chase this. > > I've attached a simple patch that restores the fallback behaviour (return > strdup(filename);) which it did prior to pr/108350. > > Regards, > Rink >
