5 ms·
The main issue is that even though C has typedefs like intmax_t that are supposed to help implementations modify them depending on compiler and platform support
by LegionMammal978 5y ago
The main issue is that even though C has typedefs like intmax_t that are supposed to help implementations modify them depending on compiler and platform support, in practice, ABI requirements force these typedefs never to change if programs ever link to external functions with them. This can also be seen in time_t, which could not easily be switched to 64 bits due to existing interfaces that expect 32-bit time_t values.
For how transparent aliases help solve this, suppose that there is some ancient library function called get_year:
typedef int32_t time_t;
int get_year(time_t time);
// document time_t and get_year
Then, library users will call get_year with 32-bit time_t values. But suppose that eventually, as Y2038 draws near, the library writers want get_year (and related functions) to instead take 64-bit time_t for all newly compiled programs that use get_year. Previously, this was impossible: users would have to modify their programs to call a new version of every function, or link to a new version of the library. But with transparent aliases, library writers can simply replace the headers with:
typedef int64_t time_t;
int get_year_v2(time_t time);
_Alias get_year = get_year_v2;
// document time_t and get_year
Now, existing compiled programs continue to call get_year in the library, which remains implemented for compatibility. Meanwhile, newly compiled programs instead call get_year_v2, without having to modify their source code at all! This enables types such as time_t and intmax_t to be transitioned without breaking any code.
- vlovich123 5y agoThe problem I see with that is what happens if you have dynamic library C (globe) and application A that’s rebuilt but library B (which sits between A and C) hasn’t. Now you have a linking error. What happens if you rebuild B and C but A hasn’t been rebuilt. That means B still needs to know to set up aliases for back compat (which you won’t find out until runtime). What if library B is yielding the changed ABI type and A is feeding it to C? I think it’s a useful tool but I don’t think it’s an ABI versioning panacea (even c++ adoption of inline namespaces within libraries is limited with the standard library being the only place I’ve seen it used in a meaningful way).
- duped 5y agothe solution is to stop linking libraries globally
- wizzwizz4 5y agoThen you raise the number of libraries in your program to some power > 1, due to the proliferation of versions. Hope you're using compile-time LTO with code deduplication!
- duped 5y agoMost libraries are not shared, even when they are ostensibly "shared" libraries. Plus disk is cheap, it seems dumb to optimize for it in the 21st century. You don't need LTO for dead code elimination.
- KerrAvon 5y agoA number of libraries are in fact shared. And RAM is not cheap when considered across the entire OS, and if every process has their own copy of the library, that’s a lot of RAM eaten up by needless duplication.
- vlovich123 5y agoIs that necessarily true in a world of zram?
- salawat 5y agoCPU cycles are still quite expensive, I assure you. It adds up.
- duped 5y agoIt's negligible, for example : https://drewdevault.com/dynlib https://drewdevault.com/dynlib
- 5y ago
- brandmeyer 5y agoIts not nearly enough to cover scalar arguments. You've got to cover composite arguments. time_t, fileno_t, fpos_t, etc may appear in structs, arrays, etc.
- KerrAvon 5y agotypedef int64_t time64_t; And the new code adopts get_year_64 directly and you don’t blow up system complexity with features that you don’t really need.