The value needs to be passed around in bytes (to support existing code and also importantly maintain resolution), it's not just the issue of reading the size from disk. Though that does the question of doing that - I'd want to maintain accuracy so would need the true size of disks/files rather than the more granular block sizes.
I'm not confident of patching the compiler with experimental code. SAS/C 6.5x is a restriction at the moment.
I'm thinking of using two longs to hold the data, even if that makes calculations interesting. UtilityBase functions may be suitable for that, otherwise I'll roll my own. This way existing code will continue to work as it does today (little-endian style) and new code can be adapted to see the higher bytes.
Then I need to work out how to write that as human readable - converting to display in MB/GB/TB I think should be okay as by that point the calculation will leave a single long suitable for sprintf, but starting to worry myself about how to get the large >2^32 byte values out in ASCII.