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

[Maciej W. Rozycki]

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

  Maciej