4 ms·
The problem isn't big-endian, its just platforms where sizeof(size_t) != sizeof(int). I believe the problem is the legacy vim API takes an (int ), so that code
by octo_t 12y ago
The problem isn't big-endian, its just platforms where sizeof(size_t) != sizeof(int).
I believe the problem is the legacy vim API takes an (int ), so that code will also need to be corrected:
char_u *string_convert_ext __ARGS((vimconv_T *vcp, char_u *ptr, int *lenp, int *unconvlenp));
- aktau 12y agoArticle author here. You're correct. It's new code that's calling into old, unrefactored code. Hence the casts. convert_input() is new, string_convert_ext() is old. As is mentioned in the article, I'm working on a refactoring of string_convert_ext() that will obviate the casting (and incidentally also some allocating).
- deleted 12y ago[deleted]
- dllthomas 12y ago"The problem isn't big-endian, its just platforms where sizeof(size_t) != sizeof(int)." To be honest, my memory is failing me, so I would appreciate it if someone with a fresher understanding of the standards or BE compiler behavior would clarify. Does a cast from (pointer to int32_t) to (pointer to int64_t) change the memory location referred to? My assumption would be not. If it does not, then there is a problem with this code on big-endian systems that does not exist on little-endian systems: On a little-endian system, you are only reading/writing the low bits of the lengths. If anything won't fit in an int, that can be a problem. It seems plausible that other things (buffer sizes?) guarantee that can never occur, though it would still be better code not to rely on it. On a big-endian system, you are only reading/writing the high bits of the lengths as if they were the low bits. That will almost always be wrong.