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

[Maciej W. Rozycki]

On Thu, 4 Dec 2025, Adhemerval Zanella Netto wrote:

> >> 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++.

 For C++ I think it's at best a grey area, just as it would say for Ada or 
Fortran, and can be handled if an actual issue actually arises.

> > 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.

 And a cheap one too, amounting to an #if or #ifdef in one place in 
sysdeps/unix/sysv/linux/alpha/bits/typesizes.h.

> 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.

 Perhaps indeed this is the pragmatic path of least resistance solution.  
The risk seems low as in the POSIX API the data type is AFAICT only ever 
used for a struct member that is supposed to never take a negative value. 
So this could only trigger for a user app that say reused the data type 
for a function's return value where a negative status indicates an error.  
And then it affects a legacy platform only.

 In that case I think we should document the quirk in "The meaning of the 
File Attributes" section of our manual though, along the lines of:

"For historical reasons this type is unsigned on Alpha Linux/GNU systems."

  Maciej