Void cast as a function

[blueskull]

I just came across this in uC-OS3 source code. What does it do?
I didn't include the real source for for copyright reasons. Here's a similar one:

static void x(int y)
{
    (void)&y;
}

I really can't think of what it does, besides to mute the unused variable warning from the compiler.
Any suggestions?

[Yansi]

Probably only really to mute the unused warning.

This is how the "unused" macro is usually done:

Code: [Select]

#define UNUSED(x) ((void)(x))

[legacy]

It passes the address of a function as uint32_t.
Then it converts back the uint32_t into a function_pointer
(it assumes it's void, no return arguments).
And It jumps into it.

[newbrain]

It passes the address of a function as uint32_t.
Then it converts back the uint32_t into a function_pointer
(it assumes it's void, no return arguments).
And It jumps into it.

How do you read all of this in the code snippet from blueskull?
There no cast to function pointer, just to void.
What is strange is the use of the address operator.
Am I missing something?

[mib]

   That is not a cast to a function pointer. Not even close.


It's all about suppressing warnings. Back in the distant past it was surprisingly difficult to suppress the unused variable warning without actually generating any code. So people came up with nonsense like this. It does nothing, just ignore it.


These days compilers are smart enough to handle more obvious ways of suppressing the warning. Or you just don't name the argument and that avoids the warning.

[Kjelt]

It's all about suppressing warnings. Back in the distant past it was surprisingly difficult to suppress the unused variable warning without actually generating any code. So people came up with nonsense like this. It does nothing, just ignore it.
These days compilers are smart enough to handle more obvious ways of suppressing the warning. Or you just don't name the argument and that avoids the warning.

True, still compilers today are so smart they throw away unused strings of for instance program version information.
I always add a string at the start of my code with the ProductName, SVN commitnr, Date and compiler version.
Why? Because when I read out a uC I can directly see if it is the correct code for the product and which version, it sometimes is a big timesaver.

When I don't use the pointer to that string somewhere in the code the compiler even in non-optimized mode will just throw it away, but then it is not a great compiler
So something like this could also be used for that purpose.

[glarsson]

It passes the address of a function as uint32_t.
Then it converts back the uint32_t into a function_pointer

If this is supposed to be C then you can not do this. Pointers to data and pointers to functions are not compatible. No use of casts or other tricks can get around this.

[grumpydoc]

I just came across this in uC-OS3 source code. What does it do?
I didn't include the real source for for copyright reasons. Here's a similar one:

static void x(int y)
{
    (void)&y;
}

I really can't think of what it does, besides to mute the unused variable warning from the compiler.
Any suggestions?

As written that code fragment does nothing - it takes the address of the parameter y but does nothing with it. The cast to void will just prevent the compiler issuing a "value not used" warning.

It passes the address of a function as uint32_t.
Then it converts back the uint32_t into a function_pointer

If this is supposed to be C then you can not do this. Pointers to data and pointers to functions are not compatible. No use of casts or other tricks can get around this.

Largely yes - in this case &y is the address of a parameter, in most architectures it will be on the stack so using it as a function address will almost certainly not produce a useful result.

That said maybe one could contrive for someting useful to happen depending on the exact architecture by taking the address of a variable and using it as a function pointer but that is really horrible code with no role outside some sort of obfusicated C contest.

But C generally makes no distinction between a data address and a function address - anything which can be cast to a function pointer type can be used to call a function.

It would be perfectly legal C to say¹

    (void (*)())(&y)();


[1] I think - bit rusty on such arcanery.

NB https://cdecl.org/ is *very* useful for figuring out the syntax for complex declarations and casts.

[Jeroen3]

6.3.2.2 void
1 The (nonexistent) value of a void expression (an expression that has type void) shall not
be used in any way, and implicit or explicit conversions (except to void) shall not be
applied to such an expression. If an expression of any other type is evaluated as a void
expression, its value or designator is discarded. (A void expression is evaluated for its
side effects.)

It makes the compiler ignore y.
However, some compilers then throw a "statement has no effect" warning, that is where the & is for, I think.
It first takes the address, then discards it.

Anyway, if you don't like it, use __attribute__((unused)) or whatever your compiler has to offer for that.
yay standards 

NB https://cdecl.org/ is *very* useful for figuring out the syntax for complex declarations and casts.

Cool.

[dmills]

When I don't use the pointer to that string somewhere in the code the compiler even in non-optimized mode will just throw it away, but then it is not a great compiler
So something like this could also be used for that purpose.

If it does that with something like

Code: [Select]

volatile const char id_string [] = "Foo Bar Baz"; then it is broken (And yes, a volatile const is a reasonable thing in embedded programming), on the other hand

Code: [Select]

const char * id_string = "...."; is fair game in all probability.

Now there are plenty of broken C compilers in the embedded space (I remember, painfully, one which started ignoring volatile when you turned the optimiser on, a nasty surprise....).

Regards, Dan.

[helius]

Depending on compiler settings, I can imagine that (void)&y; also forces y to be copied into the callee stack area (because you cannot take the address of a register). This may not happen if the "useless" statement is eliminated as dead code.

[Kjelt]

If it does that with something like

Code: [Select]

volatile const char id_string [] = "Foo Bar Baz"; then it is broken (And yes, a volatile const is a reasonable thing in embedded programming), on the other hand

Code: [Select]

const char * id_string = "...."; is fair game in all probability.

It is arguable if the volatile keyword would matter IF the variable itself (id_string) is never ever used in the code anywhere else. The compiler could conclude it is declared but never used so can be discarded.

Besides is a "volatile const" not a contradiction since the volatile is used for variables which value could change unexpectedly and const's never change ?
Anyway it does not work for that specific compiler (STM8 cosmic compiler) so I do have to use the pointer somewhere in the code.

[grumpydoc]

Besides is a "volatile const" not a contradiction since the volatile is used for variables which value could change unexpectedly and const's never change ?

No, think of some memory mapped read only register.

It can change without the code doing anything to it so needs to be marked volatile.

It cannot be modified so needs to be marked const

[Kjelt]

Ah yeah you're correct 

[legacy]

Code: [Select]

#include "lib_debug_v1.h"
#include "types.h"

/*
 * type (*function)(argtypes);
 */

typedef void (*func_t)();

void do_call
(
    uint32_t function_addr
)
{
    func_t foo;
 // void (*foo)(void);

    foo = (void *)function_addr;
    foo();
}

void hallo()
{
    printf("hAllo\n");
}

int main()
{
    uint32_t addr;

    addr = (uint32_t) hallo;
    do_call(addr);
    return 0;
}

yup, sorry.

The above is what I described.
As you can see it's different.

[NivagSwerdna]

IMHO it's because the original developers used 'lint' and the void cast is to tell lint that the passed parameter is used*. 

For the avoidance of doubt I am referring to the C static analysis tool rather than the pocket fluff you might find in your dressing gown.

*used in the sense that a subsequent developer would provide a more interesting implementation at a later date with the parameter being useful to them.

[janoc]

IMHO it's because the original developers used 'lint' and the void cast is to tell lint that the passed parameter is used*. 

For the avoidance of doubt I am referring to the C static analysis tool rather than the pocket fluff you might find in your dressing gown.

*used in the sense that a subsequent developer would provide a more interesting implementation at a later date with the parameter being useful to them.

You don't need to use lint (anyone still uses that?). You will get similar warning about unused function parameters or variables from GCC and Clang by default if you use the
-Wall option, as you probably should. In plenty of places it is against the policy to turn the warnings off so hacks like the above are common to silence spurious warnings.

However, I am actually quite shocked how many people here are unable to read a simple C declaration - a function pointer? Seriously?

Some may find this guide useful - helps to decode even the most gnarly C declarations:
http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html

[NivagSwerdna]

You don't need to use lint (anyone still uses that?). You will get similar warning about unused function parameters or variables from GCC and Clang by default if you use the

I believe the OP is an archaeologist, I was trying to explain the behavior of our ancestors.

(*explain)();

[lujji]

Compile and look at the assembly - it does nothing. There is one use case for this expression though - sometimes you want to read peripheral register and discard it's value.

Code: [Select]

#define ADCR (*(volatile uint8_t *)(0xDEFEC8))

(void) ADCR; // read access


[mib]

When I don't use the pointer to that string somewhere in the code the compiler even in non-optimized mode will just throw it away, but then it is not a great compiler
So something like this could also be used for that purpose.

If it does that with something like

Code: [Select]

volatile const char id_string [] = "Foo Bar Baz"; then it is broken (And yes, a volatile const is a reasonable thing in embedded programming), on the other hand

Code: [Select]

const char * id_string = "...."; is fair game in all probability.

Now there are plenty of broken C compilers in the embedded space (I remember, painfully, one which started ignoring volatile when you turned the optimiser on, a nasty surprise....).

Any non-static global variable, regardless of type, has to be preserved by the compiler even if you don't use it. The compiler has no way to know that it isn't used from another file. A compiler would have to be unusably broken to get that wrong.

The linker however is a different matter. You usually tell the linker to discard unused symbols when building embedded stuff to keep the size down. Most linkers also have an option to preserve specific symbols or those matching a pattern even if they're not used. That's there specifically for this use case.

[NivagSwerdna]

You don't need to use lint (anyone still uses that?). You will get similar warning about unused function parameters or variables from GCC and Clang by default if you use the
-Wall option, as you probably should. In plenty of places it is against the policy to turn the warnings off so hacks like the above are common to silence spurious warnings

https://doc.micrium.com/display/osiiidoc/MISRA+C%3A2012

[Kjelt]

IMO it is worse to use these kind of "bogus" compiler satisfying code then to disable a certain warning for Lint around the cause, so if one line throws a warning put a disable and re-enable around it with in the comments the reason why you disabled the Lint warning for that line. At least any following programmer will understand what has been done and why.

[Yansi]

It's all about suppressing warnings. Back in the distant past it was surprisingly difficult to suppress the unused variable warning without actually generating any code. So people came up with nonsense like this. It does nothing, just ignore it.
These days compilers are smart enough to handle more obvious ways of suppressing the warning. Or you just don't name the argument and that avoids the warning.

True, still compilers today are so smart they throw away unused strings of for instance program version information.
I always add a string at the start of my code with the ProductName, SVN commitnr, Date and compiler version.
Why? Because when I read out a uC I can directly see if it is the correct code for the product and which version, it sometimes is a big timesaver.

When I don't use the pointer to that string somewhere in the code the compiler even in non-optimized mode will just throw it away, but then it is not a great compiler
So something like this could also be used for that purpose.

Declare the string volatile const. Won't get thrown out then.

[ejeffrey]

True, still compilers today are so smart they throw away unused strings of for instance program version information.
I always add a string at the start of my code with the ProductName, SVN commitnr, Date and compiler version.
Why? Because when I read out a uC I can directly see if it is the correct code for the product and which version, it sometimes is a big timesaver.

When I don't use the pointer to that string somewhere in the code the compiler even in non-optimized mode will just throw it away, but then it is not a great compiler
So something like this could also be used for that purpose.

The reason turning off optimization doesn't stop this is because it isn't the compiler doing it, it is the linker (with help from the compiler of course).  If you compile with -fdata-sections it will put each global variable and constant in its own section of the object file (assuming ELF object format or similar).  The linker then does garbage collection and eliminates unused sections from the output.  You can fix this by using KEEP in your linker script, or an equivalent __attribute__.

This is completely different from how unused local variables are eliminated by compiler optimization.  Global variables and functions are placed by the linker at compiler time.  Automatic variables are allocated at runtime.

[Kjelt]

Yes I think you guys are right, it is the linker, should have known better.