[PATCH v3] Fix POSIX compliance: Make blkcnt_t and blksize_t signed on alpha

[Adhemerval Zanella Netto]

On 03/12/25 03:29, Maciej W. Rozycki wrote:
> On Mon, 1 Dec 2025, Adhemerval Zanella Netto wrote:
> 
>>>> This is essentially an ABI break, albeit I think it should not matter for most
>>>> usercases.  In theory it might break some usercases where the struct is used in
>>>> C++ function call (thus changing the mangling name) without a module rebuild.
>>>>
>>>> I am not sure how to properly fix it, I don't recall any change where we did
>>>> this. Usually we add new types, as like the 64-bit time_t stat support, to
>>>> avoid it.
>>>
>>> Even if it is an ABI break, what choice do we have? I think we shouldn't
>>> keep using incorrect types.
>>
>> I am really not sure how to proper fix it without potentially breaking the C++
>> ABI.  Maybe we can do it and document on the NEWS entry on the
>> "Deprecated and removed features, and other changes affecting compatibility"
>> about a potentially ABI break and why have changed on Alpha.
> 
>  Hmm, POSIX concerns the C programming language only.
> 
>  Would it be completely outrageous if we retained the current data types 
> for the C++ programming environment while changing their signedness only 
> for C to match POSIX?  

I think this can be an option, although it won't fix the original problem
in full if users want to use C++.

> An opt-in feature preprocessor macro functionally 
> along the lines of _FILE_OFFSET_BITS=N could also be made available for 
> software to request at application compilation time to switch the data 
> types for C++ as well (perhaps an overkill for a largely legacy target).

This is really an overkill, alpha is the only outlier and not a widely
available architecture.

For the context provided in the bug report [1], the issues is from a
_Static_assert tat is already being handled in the m4 project. I am
more inclined in not act on this issue unless this is a read issue
where the non-POSIX compliance is causing some semantic or usability
issue.

[1] https://lists.gnu.org/archive/html/bug-m4/2025-09/msg00000.html