RFR: 8354941: Build failure with glibc 2.42 due to uabs() name collision

[Andrew Haley]

On Thu, 17 Apr 2025 12:31:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> glibc 2.42 defines its own version of `uabs` when `stdlib.h` is being included. I propose to rename the hotspot version of `uabs` to `custom_uabs` (or some other suitable name) to avoid the name clash. The rename of the function is hidden by using a `UABS` macro instead in the code.
> 
> Testing:
> - [x] GHA (also [here](https://github.com/jerboaa/jdk/actions/runs/14513365723))
> - [x] Builds with this patch with GCC 15 where the build would fail earlier and pass with this patch.
> 
> Thoughts?

`uabs()` is a new C2Y function, and its definition is entirely compatible with that in globalDefinitions.hpp.  IMVHO it makes sense for us to use `uabs()`, in anticipation of C2Y.


 -- Function: unsigned int uabs (int NUMBER)
 -- Function: unsigned long int ulabs (long int NUMBER)

     Preliminary: | MT-Safe | AS-Safe | AC-Safe | *Note POSIX Safety
     Concepts::.

     These functions return the absolute value of NUMBER.

     Most computers use a two’s complement integer representation, in
     which the absolute value of ‘INT_MIN’ (the smallest possible ‘int’)
     cannot be represented; thus, ‘abs (INT_MIN)’ is not defined.  Using
     ‘uabs’ avoids this.

     '‘uabs’, ‘ulabs’, ‘ullabs’ and ‘uimaxabs’ are new to ISO C2Y.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24723#issuecomment-2820832515