An end to implicit fall-throughs in the kernel

Posted Aug 10, 2019 13:31 UTC (Sat) by johill (subscriber, #25196)
In reply to: An end to implicit fall-throughs in the kernel by danieljo
Parent article: An end to implicit fall-throughs in the kernel

# define __fallthrough /*something else*/

doesn't work one though - the preprocessor will remove the comment, rather than place it

An end to implicit fall-throughs in the kernel

Posted Aug 11, 2019 1:03 UTC (Sun) by nybble41 (subscriber, #55106) [Link] (4 responses)

Since GCC 7 there is a GCC attribute you could use in place of the comment:

#if !defined(__fallthrough) && defined(__has_cpp_attribute)
  #if __has_cpp_attribute(fallthrough)
    #define __fallthrough [[fallthrough]]
  #elif __has_cpp_attribute(gnu::fallthrough)
    #define __fallthrough [[gnu::fallthrough]]
  #endif
#endif

#if !defined(__fallthrough) && defined(__has_attribute)
  #if __has_attribute(__fallthrough__)
    #define __fallthrough __attribute__((__fallthrough__))
  #endif
#endif

#if !defined(__fallthrough) /* well, we tried */
  #define __fallthrough ((void)0)
#endif

An end to implicit fall-throughs in the kernel

Posted Nov 19, 2019 15:26 UTC (Tue) by ballombe (subscriber, #9523) [Link] (3 responses)

Is there a way to say that _all_ the cases in a given switch fall through ? This is very common and
adding 'fall through' at each line instead of once is counterproductive.

An end to implicit fall-throughs in the kernel

Posted Nov 21, 2019 16:04 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

> very common

Do you have an example to show? Other than Duff's device (which I also wouldn't classify as "very common" since it's a stereotypical "what's this weird piece of C doing" snippet), what's the use case?

An end to implicit fall-throughs in the kernel

Posted Nov 24, 2019 22:06 UTC (Sun) by ballombe (subscriber, #9523) [Link] (1 responses)

Handling a data structure with variable length.
switch (strlen(s)-1)
{
case 3: a[3] = cvt3(s[3]);
case 2: a[2] = cvt2(s[2]);
case 1: a[1] = cvt1(s[1]);
case 0: a[0] = cvt0(s[0]);
}
or
switch(a.dim)
{
case 4: checkt(a.t);
case 3: checkz(a.z);
case 2: checky(a.y);
case 1: checkx(a.x);
}

finishing after a loop unrolling

for(i=l;i>=3;i-=4)
{ f(i); f(i-1);f(i-2);f(i-3);}
switch(i)
{
case 3: f(3);
case 2: f(2);
case 1: f(1);
case 0: f(0);
}

conversion
switch(type(z))
{
case FOO: z = FOO_to_BAR(z);
case BAR: z = BAR_to_BAZ(z);
case BAZ: return process_BAZ(z);
}

An end to implicit fall-throughs in the kernel

Posted Nov 25, 2019 16:35 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> Handling a data structure with variable length.

The first seems like abusing a C string for data storage. A better data structure seems relevant here. It would certainly make the code clearer.

> a.dim

I feel like this would be wrapped up better in a `checkvec` function in the first place. Though this is C; why is one abusing a vec4 to store vec3 or vec2 information (losing cache line benefits given the usual suspects for code using such structures).

> loop unrolling

Something I expect the compiler to be better at today than myself (pending benchmarks showing that the vectorization/unrolling isn't happening).

> conversion

Well, this is what you get with crappy type hierarchies :) . I think the normal way would be something like:

baz* p = NULL;
switch(type(z)) // Assuming `z` is some kind of tagged union structure.
{
case FOO: p = &z->foo.baz; break;
case BAR: p = &z->bar.baz; break;
case BAZ: p = &z->baz;
}
if (p) process_BAZ(p);

These are interesting use cases, but I still wouldn't classify them as "common" or even idiomatic.