Broadcom Open-Sources Wireless Drivers

The ternary operator is dissapointed.


/*
Description: This function saturate input 32 bit number into a 16 bit number.
If input number is greater than 0x7fff then output is saturated to 0x7fff.
else if input number is less than 0xffff8000 then output is saturated to 0xffff8000
else output is same as input.
*/
int16 qm_sat32(int32 op)
{
    int16 result;
    if (op > (int32) 0x7fff) {
        result = 0x7fff;
    } else if (op < (int32) 0xffff8000) {
        result = (int16) (0x8000);
    } else {
        result = (int16) op;
    }
    return result;
}

>>40
Use typeof instead of void * and also store the result somewhere because in that block it's just being discarded.

>>39
That's why it is in UPPERCASE. Generally, uppercase is used for macros, and especially ones that might re-evaluate their arguments.
Someone who is too dumb to use these sorts of tools should stay away from them. That doesn't mean that they're bad.

>>40 is a tremendously stupid implementation and assumes that x2, low2, and high2 aren't already names in use elsewhere in the code. With -Wshadow (which, btw, can be a tremendous help in tracking down otherwise highly obscure problems sometimes) such code would have to unnecessarily be rewritten. Don't be hostile to your users for the sake of idiots' safety. That's what Java is for, not C.

>>42
Agreed. As a general rule I use uppercase only for badly behaved macros (either they evaluate their arguments multiple times, or they open a block and cannot be used in an expression, or something else funny.) If a macro behaves like a function, then you won't need to know it's not a function, so there is no reason it can't be named like a function.

If >>40 enclosed the block in parens (making it a statement expr) and used typeof it would actually work in GCC, Clang, and a few others. I'd rather have portability though.

In any case clamp() is a completely retarded and brain-dead example because there is no reason it shouldn't just be a function.

>>43
You can't take the address of macros. It's better to just follow the uppercase convention for all macros, unless you're specifically trying to replicate some other function with a macro (e.g. C standard library)

>>41
typeof is nonstandard, as is anything that would allow a code block to evaluate to a value.

>>44
Actually I'd argue that it's better to not expect to be able to take the address of any function willy-nilly. You should have good reason for using a function pointer.

there is no reason it shouldn't just be a function
Not having to make a bunch of stupid function calls in a tight inner loop of speed-critical code, for something that's very easily and efficiently handled as a macro?

#include <stdint.h>

#define clampx(x,T)                           \
  static inline T clamp##x(T n, T lo, T hi) { \
    if (n < lo) return lo;                    \
    if (n > hi) return hi;                    \
    return n;                                 \
  }

clampx(i, int)
clampx(l, long)
clampx(ll, long long)
clampx(j, intmax_t)

#undef clampx

#define clamp(n,lo,hi) _Generic((n)+(lo)+(hi),        \
                                int:         clampi,  \
                                long:        clampl,  \
                                long long:   clampll, \
                                default:     clampj   \
                               )((n),(lo),(hi))

>>46
It's too bad there's no way we could get the compiler to substitute the function right into the call site and avoid the call entirely.

>>48
Yes, it's too bad C is stupid.

Let's just use Lisp instead where such things aren't goddamn foreign.

>>49
>>48 was being sarcastic. Most C compilers do that.

>>49-50
C compilers tend to have an inlining extension, such as __inline/declspec stuff. Common Lisp implementations have inline/notinline declarations as well, however unlike the C ones, those are specified in the standard, however some Lispers(including me), believe that those 2 are themselves not enough as one might want to be able to control wether function calls are direct or indirect too, which is more important in Lisp as it allows redefinition at runtime (of just about anything you can think of).

>>51
inline is part of C99, why aren't you using that already.
(not that it's anything more than a suggestion to compilers)

static inline template<class T> T clamp(T x, T low, T high) {
  return (((x) > (high)) ? (high) : (((x) < (low)) ? (low) : (x)));

>>53
{{{{ CLOSE YOUR BRACES }}}}

The way everyone blathers on about performance, you'd think prog was entirely filled with people programming games on the last generation's consoles.

>>55
How do you know it's not?

>>56
Because every thread except this one is filled with toy languages (languages other than C).

>>57
back to /1970s/, please

Xarn is a bad boyfriend