4 ms·
Are these supposed to do different things on different architectures, or do they magically do the same thing without comparing C1 in the "else" case? #if (NG
by SoftwareMaven 13y ago
Are these supposed to do different things on different architectures, or do they magically do the same thing without comparing C1 in the "else" case?
#if (NGX_HAVE_LITTLE_ENDIAN && NGX_HAVE_NONALIGNED)
#define ngx_str3Ocmp(m, c0, c1, c2, c3). \
*(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0)
#else /* !(NGX_HAVE_LITTLE_ENDIAN && NGX_HAVE_NONALIGNED) */
#define ngx_str3Ocmp(m, c0, c1, c2, c3) \
m[0] == c0 && m[2] == c2 && m[3] == c3
- sltkr 13y agoIf you look at where they are used, then it looks like these macros do not need to compare m[1] to c1 because whenever they are used it is already known that m[1] == 'O' (hence "str3O" in the name -- that's 3 and the letter O, not number zero). I guess c1 is included in the first case because it's faster to compare the whole 32-bit word than mask out the known byte (and since c0, c1, c2 and c3 are compile time constants, the whole right-hand-side of the comparison will be optimized by constant folding anyway). (It's ridiculous micro-optimization in my opinion, but at least it is correct, and it is limited to a single file.)
- paraboul 13y agoThat's because c1 is always 'O' (in order to compare things like : 'POST', 'COPY', 'MOVE', etc.) In the first case, comparing 2 integer (4x 8bit) is faster than omitting one byte. That's is, using ngx_str3Ocmp with c1 != 'O' would be a usage error. Edit: sltkr, sorry didn't see your reply.