What is the function of "(void) (&_min1 == &_min2)" in the min macro in kernel.h?

Question

In kernel.h min is defined as:

#define min(x, y) ({                \
    typeof(x) _min1 = (x);          \
    typeof(y) _min2 = (y);          \
    (void) (&_min1 == &_min2);      \
    _min1 < _min2 ? _min1 : _min2; })

I don't understand what the line (void) (&_min1 == &_min2); does. Is it some kind of type checking or something?

Curious. It seems to me that the address comparison would force _min1 and _min2, and therefore x and y, to actually be computed and stored, but shouldn't that happen anyway when _min1 is compared against _min2 in the next line? — michel-slm, Apr 08 '11 at 13:21
FYI, the question [Macro with an unusual line in linux kernel?](http://stackoverflow.com/questions/26717636/macro-with-an-unusual-line-in-linux-kernel) was merged with this one, so you have a a few new answers now. — Shafik Yaghmour, Nov 14 '14 at 01:52

pmg · Accepted Answer · 2020-05-17T20:25:02.160

64

The statement

(void) (&_min1 == &_min2);

is a guaranteed "no-op". So the only reason it's there is for its side effects.

But the statement has no side effects!

However: it forces the compiler to issue a diagnostic when the types of x and y are not compatible.
Note that testing with _min1 == _min2 would implicitly convert one of the values to the other type.

So, that is what it does. It validates, at compile time, that the types of x and y are compatible.

edited May 17 '20 at 20:25

answered Apr 08 '11 at 13:24

pmg

106,608
13
126
198

3

Maybe it's better to say that it has no _runtime_ side effects, but rather _compilation_ side effects. – J. Polfer Apr 08 '11 at 13:28
That doesn't sound right to me for some reason. If the types are incompatible, then the macro won't work anyways. I.e., if you pass the macro a struct foo and an int you'll get a compile time error anyways, even without that line. – Robert S. Barnes Apr 08 '11 at 14:11
2

@Robert: try, for instance, `m = min(42, 43.0);`. Both with and without the statement in question. – pmg Apr 08 '11 at 14:18
@pmg: So the point isn't incompatible types, it's that they want to ensure that both arguments are of the exact same type? – Robert S. Barnes Apr 08 '11 at 14:21
2

`int` and `volatile const int` are distinct, but compatible, types! – pmg Apr 08 '11 at 14:29
@pmg: Good catch. The macro should probably be using `typeof((x)+0)` rather than `typeof(x)`... – R.. GitHub STOP HELPING ICE Apr 08 '11 at 14:52
@R..: the sane version has my vote! Anyway, adding `+0` would make `char`, `short`, and `int` all compatible :) – pmg Apr 08 '11 at 15:24

Hasturkun · Answer 2 · 2014-11-03T15:55:32.157

20

The code in include/linux/kernel.h refers to this as an "unnecessary" pointer comparison. This is in fact a strict type check, ensuring that the types of x and y are the same.

A type mismatch here will cause a compilation error or warning.

edited Nov 03 '14 at 15:55

answered Nov 03 '14 at 15:49

Hasturkun

35,395
6
71
104

But what is going to happen if they are not the same? Seems like the code will run anyway. – user10607 Nov 03 '14 at 15:53
Isn't this wasting cpu time on equality check ? – Nico Nov 03 '14 at 17:42
3

No, it's a nop. It's called in void context so the results don't matter, an optimizer would eliminate it completely. – Hasturkun Nov 03 '14 at 17:43
@Hasturkun you mean this line would not make it into the executable? – user10607 Nov 03 '14 at 18:43
1

@user10607: Yes. It has no side effects whatsoever and its results are discarded, there would be no reason to keep it. – Hasturkun Nov 03 '14 at 18:45
@Hasturkun so this line does its work during preprocessor stage to generate warnings/errors and then gets erased? – user10607 Nov 03 '14 at 19:39
1

@user10607: No. It is compiled (where the magic of type checking occurs), and is later discarded by the optimizer (still during the compilation phase). – Hasturkun Nov 03 '14 at 19:42
Merged from http://stackoverflow.com/questions/26717636/macro-with-an-unusual-line-in-linux-kernel – Shog9 Nov 13 '14 at 21:26
This should be the accepted answer as it contains no guess. – Sebastian Mach Nov 28 '14 at 14:34

score 12 · Answer 3 · edited Aug 26 '20 at 21:52

This provides for type checking, equality between pointers shall be between compatible types and gcc will provide a warning for cases where this is not so.

We can see that equality between pointers requires that the pointers be of compatible types from the draft C99 standard section 6.5.9 Equality operators which says:

One of the following shall hold:

and includes:

both operands are pointers to qualified or unqualified versions of compatible types;

and we can find what a compatible type is from section 6.2.7 Compatible type and composite type which says:

Two types have compatible type if their types are the same

This discussion on osnews also covers this and it was inspired by the GCC hacks in the Linux kernel article which has the same code sample. The answer says:

has to do with typechecking.

Making a simple program:
int x = 10; 
long y = 20;
long r = min(x, y);
Gives the following warning: warning: comparison of distinct pointer types lacks a cast

Merged from http://stackoverflow.com/questions/26717636/macro-with-an-unusual-line-in-linux-kernel — Shog9, Nov 13 '14 at 21:26

score 7 · Answer 4 · answered Apr 08 '11 at 13:30

See http://www.osnews.com/comments/20566 which explains:

It has to do with typechecking.

Making a simple program:
int x = 10; 
long y = 20; 
long r = min(x, y); 
Gives the following warning: warning: comparison of distinct pointer types lacks a cast

score 4 · Answer 5 · answered Nov 03 '14 at 15:50

4

Found answer here

"It has to do with typechecking. Making a simple program:

int x = 10; 
long y = 20; 
long r = min(x, y);

Gives the following warning: warning: comparison of distinct pointer types lacks a cast"

answered Nov 03 '14 at 15:50

incogn1to

429
4
17

Merged from http://stackoverflow.com/questions/26717636/macro-with-an-unusual-line-in-linux-kernel – Shog9 Nov 13 '14 at 21:26

score 0 · Answer 6 · answered Apr 08 '11 at 13:46

0

The Linux kernel is full of stuff like this (gratuitous gcc-specific hacks for the sake of "type safety" and other similar considerations), and I would consider it very bad practice and urge you not to follow it unless someone requires you to.

pmg is right about the purpose of the hack, but any sane person would define min as ((x)<(y)?(x):(y)).

Note that the kernel definition precludes many correct usages, e.g. where one argument is int and another is long. I suspect what they really wanted to preclude is signedness mismatches, where for example min(-1,1U) is 1. A better way to assert this would be to use a compile-time assertion for ((1?-1:(x))<0)==((1?-1:(y))<0). Note that this does not require any gcc-specific hacks.

answered Apr 08 '11 at 13:46

R.. GitHub STOP HELPING ICE

208,859
35
376
711

4

But ((x)<(y)?(x):(y)) breaks if either x or y have side-effects. In fairness to the kernel they specify GCC as their compiler so they're allowed GCC-specific stuff. – Rup Apr 08 '11 at 13:51
1

Everyone **knows** you don't pass expressions with side effects to a min/max macro. This is one of the first things you learn learning C. And specifying GCC as the only supported compiler is a hindrance to progress. – R.. GitHub STOP HELPING ICE Apr 08 '11 at 14:03
4

Sure, but I learned it the other way around: you don't write min / max as a macro like that. – Rup Apr 08 '11 at 14:10
1

Macro is the only way to make it work with multiple types (float, pointers, integers, signed or unsigned). There *are* ways to make it avoid evaluating them more than once, but they're sufficiently painful and make the macro gigantic and unreadable that I don't think they're worth it. A good C programmer will be cautious about side effects here anyway, and it's much more important that the macro is simple and clear and obviously correct to somebody who reads it. – R.. GitHub STOP HELPING ICE Apr 08 '11 at 14:37
2

The kernel requires various other things (`asm` blocks, linker section annotations) that are not part of standard C anyway, so specifying GNU C isn't really a loss. – caf Apr 11 '11 at 12:47
@caf: There's a big difference between requiring gcc/at&t style inline assembler support for small amounts of machine-specific code, and requiring a completely different GNU variant of the C language. The former is supported by almost any C compiler for unix-like systems. The latter... well it depends on which extension you're using. – R.. GitHub STOP HELPING ICE Apr 11 '11 at 14:22
@R.. when I evaluate `((1?-1:(x))<0)==((1?-1:(y))<0)` in my mind it always evaluates to true (-1 == -1). Is the trick here to provoke a compiler warning? – Aktau Jun 16 '14 at 08:14
2

@Aktau: No. The "trick" is that it can easily be false. The result of the `?:` operator has a type whose rules depend on the types of both the second and third operand. If one of `x` or `y` has an unsigned type of rank greater than that of `int` but the other does not, the equality will be false; one will be a large positive value and the other will be -1. These are exactly the cases where `min` and `max` macros could behave in an unexpected and possibly-dangerous manner. – R.. GitHub STOP HELPING ICE Jun 16 '14 at 15:01
Excellent, another thing learned. I've heard of crazy things with the `?:` operator being used for the implementation of `tgmath.h` on some toolchains. Now I know a bit better why/how. Thanks! – Aktau Jun 16 '14 at 15:02

What is the function of "(void) (&_min1 == &_min2)" in the min macro in kernel.h?

6 Answers6

Linked

Related