4 ms·
Addressing afhof's comments... 1 & 2. I don't see any reason to believe there will ever be a new machine with non-power-of-two word size, and I'm doubtful that
by dalias 14y ago
Addressing afhof's comments...
1 & 2. I don't see any reason to believe there will ever be a new machine with non-power-of-two word size, and I'm doubtful that there are even any historical post-standardization C implementations like that. Certainly Linux, which makes much bigger assumptions about word size and the relationship of types, will never support such hypothetical systems. Generality is good if it buys you anything practical, but my approach has been to avoid excess generality unless it has a practical benefit. This approach has been very beneficial in the dynamic linker, wherein assuming that things that are the same on real-world archs actually are the same, the amount of per-arch code to maintain is only some 30 lines (which might grow to 60-100 once TLS is supported), as opposed to many hundreds or even thousands in other implementations.
At this point, musl does not have official documentation/manual. When it does, these sorts of requirements as well as all the implementation documentation required by ISO C and POSIX will be documented.
3. The casts are all necessary (C does not define implicit conversions between pointer types) and correct. Casting to (void *) rather than an explicit type is my preference because it reduces duplication of the type in multiple places, but in any case this is purely a stylistic matter and has nothing to do with the generated code or correctness.
4. The ONES macro was leftover from other files on which this code was based (strchr and strcpy). Obviously it's not needed in memcpy which copies a fixed number of bytes without searching for any terminator character, so it could/should be removed. Thanks for catching this.
- 1amzave 14y ago> I don't see any reason to believe there will ever be a new machine with non-power-of-two word size Well...obviously it's designed to run Forth and not C, but for what it's worth, this is a pretty recent machine with an 18-bit word size: http://www.intellasys.net/index.php?option=com_content&task=view&id=60&Itemid=75 http://www.intellasys.net/index.php?option=com_content&t...
- dalias 14y agoMachines with a word size that's not a multiple of 8 cannot support POSIX at all. POSIX requires CHAR_BIT==8, and to support the POSIX and C11 memory model for threads, bytes must be individually addressible without a read-modify-write cycle on a larger memory unit. So this kind of thing really is irrelevant as far as POSIX is concerned.
- malkia 14y agofunny, because POSIX came as an idea from RMS, an ex lisp machine hacker, where non-power of two words were tobe found at large
- dalias 14y agoThe lore is that the the name POSIX, not the idea for POSIX, came from RMS and was a form of disguised spite for the process (i.e. that he intended it to be read as Piece Of Shit *IX, or similar). I'm not sure whether there's any evidence to corroborate this part of the lore, but in the early days POSIX was definitely not representative of RMS's ideas/vision. These days the standards process and even the document itself are a lot more open (though still not up to RMS's standards). CHAR_BIT==8 was not mandated by POSIX until 2001 when it was aligned with C99, and seems to have been mandated as a consequence of C99's requirement that [u]intXX_t types not have any padding bits, and the requirement (in POSIX) that network-related interfaces use uint8_t, uint16_t, and uint32_t (which, per C99, cannot all exist unless CHAR_BIT==8).
- deleted 14y ago[deleted]