If you're dead set on doing this, the correct way would be to name the macro in all caps e.g. #define SIZEOF(x) as C is case sensitive. It is somewhat self-documenting to the next guy that SIZEOF() != sizeof().

Any name is fine, as long as it isn't literally "sizeof".

Considering '#defines' are done in a textual pre-precessing by the C pre-processor, they don't know much at all about the C language. You can define out int, long, struct or anything.

I have seen many people redefine 'for' and 'while'. These people often argue that it is an improvement.

  cpp
  #define sizeof(x) (size)sizeof(x)
  sizeof(UU)

^D

  # 1 "<stdin>"
  # 1 "<built-in>"
  # 1 "<command-line>"
  # 31 "<command-line>"
  # 1 "/usr/include/stdc-predef.h" 1 3 4
  # 32 "<command-line>" 2
  # 1 "<stdin>"
  (size)sizeof(UU)

> I have seen many people redefine 'for' and 'while'.

    #define while if

Also, `#define countof(a) (sizeof(a) / sizeof(*(a)))` is unsafe since the arg is evaluated twice.

This is a very common macro to get static array lengths and i'm not sure there is any other way to do the same thing (i.e. give a static array, get back the number of items in it) in any other way.

The arg is expanded twice but evaluated zero times, since sizeof gives the size of its argument type without executing anything.

countof(foo()) looks like foo() is only called once, but would actually be called twice. That's what GP is talking about, it's evaluated twice after the expansion when the code is actually running, not during the expansion.

Again no, foo isn't called at all since countof() only uses its argument in a sizeof expression.

It is not evaluated for regular arrays. It is evaluated for arrays with variable size, you need to be careful a bit. But this is rarely happens to be a problem.

The general rule for sizeof is to apply it only to variable names or directly to typenames.

Arguments to sizeof aren’t actually evaluated (except for variably-modified-types, AKA VLAs, but don’t use those).

Please use those. They are useful, make code clearer, improve bounds checking, ...

Don't let attackers influence the size of a buffer (neither for VLAs nor for heap allocations).

really? then how do you #define things like types like `int` and `char`?

For example, it would be illegal to do the following:

> #define int long

Because you're replacing the int keyword with something else.

The standard says:

> 17.6.4.3.1 [macro.names] paragraph 2: A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 3, or to the attribute-tokens described in 7.6.

That's C++. But I couldn't find the same restriction in C. In fact it seems that C allows it as long as you don't include any of the standard C header.

> 7.1.2 "Standard headers" §5 [...] The program shall not have any macros with names lexically identical to keywords currently defined prior to the inclusion of the header or when any macro defined in the header is expanded.

Searching around gave me this from stackoverflow:

In C standard, it is not allowed.

> C11, § 6.4.1 Keywords

> [...]

> The above tokens (case sensitive) are reserved (in translation phases 7 and 8) for use as keywords, and shall not be used otherwise.

https://stackoverflow.com/questions/12286691/keywords-redefi...

And so you still can re-define keywords, but only after you've included all the standard headers you want. Which makes sense: the meaning of including a standard header is entirely standard-mandated (they are not even required to be actual files) so making anything that could potentially mess with the implementation's implementation of standard headers UB is reasonable.

You don't.