"You can typedef a function declaration... and declare function prototypes..."
This is actually a very useful technique that I use all the time. It allows you to make sure that a function and any function pointers that point to it always have matching types (since you only have to change the prototype in one place - the typedef).
And that's because dlsym takes a void * - attempting to teach dlsym about every function signature (e.g. imagine it were C++ and could be genericized...) would be monstrous.
Of course, so that's where typedefed declaration may be handy - since compiler doesn't know what is going to be dlsymed, it won't tell you when the signature won't match.
I'm currently involved in function interposing. I'm interposing many functions with many different signatures, but I still need some housekeeping for each function that I interpose. The housekeeping struct has pointers for both the original function and the replaced function. These members are necessarily typed as void .
Later, when I want to call the original function, I assign to a properly typed variable to the value of the void original_function member. The compiler has no way to know if that void * is actually FILE (fopen )(char , char ) or if it's int(open )(char , int, ...).
When everything can be properly typed, I only ever get warnings about assigning the wrong function types to the wrong function pointer variables.
The potential trouble is if the function pointer goes through a void* wormhole. (All of these types will be lost... like...)
In C you can cast a pointer, okay anything really, to a function pointer and then call it.
int foo(int a, int b){return a+b; }
void *vptr = foo;
int (*yolo)(int a) = vptr;
int c = yolo(10); // Cthulhu come
This sort of thing can happen when you pass a function pointer into some sort of callback mechanism+. When you get it back you have to cast it to the right type and then call it. So there is a disconnect between the cast and the function definition, unless you tie both together with a typedef.
+ Often helpful for an api that takes a callback to also record, who the caller was and some arbitrary bit of data. The arbitary bit of data might be a function pointer.
Actually, casting between void * and void (*)() is not legal C. You can convert between pointers of different object types, and you can convert between pointers of different function types, but you're not allowed to convert between a pointer of object type and pointer of function type (c.f. N1570, §J.5.4 (which makes it explicit) and §6.3.2.3 (where it's implicit by omission)).
This is however a very common extension allowed in most compilers, since most processors that people encounter keep code and data in the same memory address pool. But on DSPs, it's common for data and code memory to be distinct address spaces, and the two pointer types aren't necessarily the same size.
Strictly speaking accessing that union both ways ~~~violates the strict aliasing rules~~~ isn't portable. However, it is such a common idiom that GCC and other compilers explicitly allow using unions to get around the strict aliasing rules, so long as the access is always performed through the union.
Type punning by casting through a union is allowed by c99/c11 in that the behavior is unspecified(not undefined) and a footnote clarified the behavior to be the expected.
From C11:
If the member used to read the contents of a union object is not the same as the member last used to
store a value in the object, the appropriate part of the object representation of the value is reinterpreted
as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type
punning’’). This might be a trap representation.
union {
int x;
float y;
} b;
b.y = 10e5;
printf("%x\n", b.x);
That behavior is legal and well-defined behavior (up to the implementation-defined nature of representations) under C99 and C11, but not under C89 and earlier. Unfortunately, although it was made legal in C99, C99 did retain the program as an example in its (non-normative) list of undefined behaviors, which doesn't help clear up its legality.
Its status under C++11 and C++14 is much more debatable. I recall (I may have bad memory) that an early draft of C++0x had incorporated new C99 text on unions, which would have made it legal, but the wording of unions changed dramatically when unrestricted unions were introduced, which means that assessing its present legality relies very heavily on how you extend initialization to types like int and float.
> All of these examples you'll see here will compile without warnings or errors even with very strict compiler flags in gcc and clang (gcc -Wall -ansi -pedantic -std=c89 main.c)
Umm, that's really not that restrictive. Use `clang -Weverything -std=c11 main.c` if you want strict warnings.
means three different things, depending on where it appears: As a function argument, it is a pointer that will be accessed like an array. As a variable with automatic storage duration, it is an array whose size will be determined by the right-hand-side of an assignment from a braced initializer list. In the middle of a struct definition, it's illegal. And at the end of a struct definition, it is a flexible array member.
My favorite is similar thing, but in C++ and much more confusing:
class Bar {};
class Foo {
public:
Foo(const Bar &c) { }
void method() { }
};
int main() {
Foo foo(Bar());
foo.method();
return 0;
}
"foo.method();" doesn't compile because:
error: request for member ‘method’ in ‘foo’, which is of non-class type ‘Foo(Bar (*)())’
That's right: "foo" is a declared function that returns instance of Foo and takes one argument - a function that returns instance of Bar :) But when you add additional parentheses in a line above:
Foo foo((Bar()));
then "foo" is an instance of Foo created by passing a new instance of Bar to its constructor, which is more like what you'd expect by reading the code, and the code compiles. Fun!
AFAIK this this was only made legal by c99. Though I have seen it in code that is much older. (Pre-c99 you would give the "flexible" member an element size inside the square brackets, such as 0 or 1, but allocate as if it were a larger size on the heap.)
I've found that a great deal of these idioms are explained in the excellent book "Advanced C Programming: Deep C Secrets" by Peter van der Linden. Its one of my goto books for when I want to enhance my 30 years of C-programming experience with a little more insight - I've read it multiple times since it was published, and always learn something new. Check it out if you want to dive more deeply into some of these oddities:
The rare technical book that rewards the reader with not merely technical excellence but also robust humor. I still read parts on occasion even though I have no need for C these days.
Seems an odd example: any code with a multiline comment can have the same issue. That's nothing to do with the strangeness of Duff's device. It would work the same in a series of function calls or calculations.
And even then it is a matter of experience. It looks odd to me to have multiline comments not in its own 'paragraph' of the code, so draws the eye right away. Perhaps this would foil some programmers, but not more than once, I'd have thought. In my experience, run-on compound statements are much more common and hard to intuitively spot:
if (foo)
bar();
sun();
Duff's device is difficult to understand from first principles, but even that is a bad example of unmaintainable code because a) it looks like nothing except Duff's device, you only need to see the pattern once or twice and you'd recognise it, and at least know 'it's that weird pattern for unrolling loops', and b) it is a performance optimisation that only belongs in code that is profiled and needs to go that fast. As such it should be well commented to avoid regressions by well meaning refactor-zealots. Inline assembly or heavy intrinsics are more difficult to read than regular C too, so you only use them when you need to. In my experience manual loop unrolling is very rarely needed.
Actually Duff's device is very likely to be a performance hit most of the time. It will have bad branch predictor behavior and it creates unstructured code, making it harder for the compiler to reason about and optimize.
Although it should be noted that the original person to use Duff's device did admit that he tried everything else to optimize it and only that worked, and he never advocated that people should use it as a general optimization technique.
That's been my experience too, not just of Duff's device but in general with trying to unroll loops. There may have been a point where it was practical (although early in my career I didn't do the profile-first-optimise-later thing very well, I confess). But if you think you can manually unroll a loop in a way that beats the branch predictor and a good compiler on most modern hardware, you're probably fooling yourself.
I suspect I'm just not in the group of people for whom it is relevant any more. Way back I was optimising for console hardware when that hardware was quite rudimentary. Now the hardware is much more sophisticated, I don't need it.
Can you say what kind of stuff and in what kinds of situations you unroll loops. Just out of curiosity.
It's worth noting that there are definitely exceptions where loop unrolling is a good practice for optimization. When writing code that will run on obscure old architectures, and even some common ones, the CPU doesn't have things like branch prediction and caches, and your compiler is likely quite rudimentary.
Not that the comment trick has anything to do with Duff's device, but any editor with syntax highlighting would display the commented-out lines in a different font, making the situation considerably more clear.
Duff's is not just about unrolling, it's mostly a way to use the 'case can be anywhere inside a switch statement'. It's used a lot for other purpose, some of them very, very handy. The stackless coroutine trick is very useful for example (see http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html )
On platforms with very little RAM (embedded) it's fantastic to be able to 'port' linear code that might have run in a thread, and convert it to a coroutine that is a lot easier to read and maintain than having to convert it all up to a 'manual' state machine.
Note that with gcc, you can reach the same results by using the 'indirect goto' that is both more powerful, and more dangerous!
void * lab;
lab = &my_label;
goto *lab;
my_label: ...
*(const char * + char *) The type of int i is converted to 'char *' and multiplied by sizeof(char)
I am pretty certain this explanation does not make any sense: what is really happening here is that the int, for purposes of the addition, is measuring units sizeof the object being pointed to; there is no meaning I know of to adding two pointers.
/* This works because "Hello"[5] == 5["Hello"].*/
At this point, you could really just say the following:
/* This works because a[b] == *(a + b), and addition is commutative. */
I had an "ohh wow" moment when I realized that the keyword typedef is a storage class. This means it can go anywhere static can go. It just means no variable is introduced, only a type name, otherwise it is the same syntax as declarations.
The bitfield example is misleading. Section 6.7.2.1/10 of the C99 standard says:
"The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined"
There is no guarantee on the order of the bits inside a bitfield. The compiler may also introduce padding, e.g. for alignment purposes. This makes bitfields unusable for unpacking binary data.
Unfortunately, you're stuck with shifting and masking to replicate the same effect.
I've had very nasty experiences with bitfields even though the order was well defined on that platform. It was an embedded system where someone got the idea to create bitfield access to a cpu register.
The problem was that some bits in that register would be cleared automatically each time, so even if you wrote 0 it would read back as 1 the next time. Some other bit would always trigger an action if you wrote to it regardless if you wrote the same value as it had before, this was called the send_bit and when you wrote 0 it sent some stuff onto the network cable. So code that looked perfectly fine like this:
Actually sent 3 packets instead of 1 because the compiler translated each write of a bitfield member to a write of the whole register, some other bits in bitsa could get corrupted by the bitsb-write since they didn't read back as they were written. I assume the cpu had a minimum addressable unit of 8 bits so the compiler had to translate each line into something like register = (register | setbits) & clearbits; which requires reading the previous value each time just to write a single bit, this is very easy to overlook when you just see the three lines of code being written in a neat sequence.
> It was an embedded system where someone got the idea to create bitfield access to a cpu register.
Most PCI/PCIe devices have memory mapped registers that behave similarly. Like DMA registers... Although it's a bit bad idea to trigger send on writing 0 bit to the corresponding bit in the register. But hardware memory mapped registers are weird and these things are common. Like writing 1-bit to clear.
Yeah, combining bitfields with volatile is an extremely bad idea. I've heard, and give some credence to, opinions using volatile at all in normal code, rather than hiding it in a helper or something, is a bad idea, given that that allows reading and writing registers to look the same as normal memory accesses, despite it having extremely different consequences.
"sent 3 packets instead of 1 because the compiler translated each write of a bitfield member to a write of the whole register"
So the problem was the fact that the language gives the impression of having more control than what the hardware is actually offering. In this case bit access must have been better left to platform-dependent libraries (when it would present itself as something more than what masks usage can do).
That's one of the few nag I have about C; this syntax is fantastic, and theoretically allow the compiler quite a lot of freedom to optimize access to the bitfield, and the fact that it was never standardized means you just can't use it if you want portable code.
Unions? Function pointers? Typedefs? While it might be bad for karma to point out, intro to C certainly isn't what I expect to be news to "hackers", as per the site's namesake.
Isn't the first example undefined behavior? I always thought you shouldn't assign data to a union using one member, then access the data using a different member.
To consider function types, or unjustified assumptions about bitfield unions, or use of parentheses to control nesting of arrays and pointers in declaration "strange" one must be averse to the C language to the point of intolerance. Backlash from working on a C compiler and wishing the task was easier?
56 comments
[ 4.8 ms ] story [ 117 ms ] threadThis is actually a very useful technique that I use all the time. It allows you to make sure that a function and any function pointers that point to it always have matching types (since you only have to change the prototype in one place - the typedef).
Later, when I want to call the original function, I assign to a properly typed variable to the value of the void original_function member. The compiler has no way to know if that void * is actually FILE (fopen )(char , char ) or if it's int(open )(char , int, ...).
When everything can be properly typed, I only ever get warnings about assigning the wrong function types to the wrong function pointer variables.
In C you can cast a pointer, okay anything really, to a function pointer and then call it.
This sort of thing can happen when you pass a function pointer into some sort of callback mechanism+. When you get it back you have to cast it to the right type and then call it. So there is a disconnect between the cast and the function definition, unless you tie both together with a typedef.+ Often helpful for an api that takes a callback to also record, who the caller was and some arbitrary bit of data. The arbitary bit of data might be a function pointer.
This is however a very common extension allowed in most compilers, since most processors that people encounter keep code and data in the same memory address pool. But on DSPs, it's common for data and code memory to be distinct address spaces, and the two pointer types aren't necessarily the same size.
If you try to cast a pointer into your function type, you'll get a runtime error, not a compile time one.
http://stackoverflow.com/questions/11639947/is-type-punning-...
union { int x; float y; } b; b.y = 10e5; printf("%x\n", b.x);
That behavior is legal and well-defined behavior (up to the implementation-defined nature of representations) under C99 and C11, but not under C89 and earlier. Unfortunately, although it was made legal in C99, C99 did retain the program as an example in its (non-normative) list of undefined behaviors, which doesn't help clear up its legality.
Its status under C++11 and C++14 is much more debatable. I recall (I may have bad memory) that an early draft of C++0x had incorporated new C99 text on unions, which would have made it legal, but the wording of unions changed dramatically when unrestricted unions were introduced, which means that assessing its present legality relies very heavily on how you extend initialization to types like int and float.
Umm, that's really not that restrictive. Use `clang -Weverything -std=c11 main.c` if you want strict warnings.
struct items_with_header { int header_field1; unsigned int length; double array[]; };
Then allocate enough memory and use the struct to access it.
Used it once in a hash-table implementation.
https://github.com/sepeth/python-skiplist/commit/00ae7f94246...
Redis's skiplist is also using the same feature:
https://github.com/antirez/redis/blob/unstable/src/server.h#...
typename identifier[];
means three different things, depending on where it appears: As a function argument, it is a pointer that will be accessed like an array. As a variable with automatic storage duration, it is an array whose size will be determined by the right-hand-side of an assignment from a braced initializer list. In the middle of a struct definition, it's illegal. And at the end of a struct definition, it is a flexible array member.
https://en.wikipedia.org/wiki/Most_vexing_parse
https://en.wikipedia.org/wiki/Most_vexing_parse#Uniform_init...
http://archive.arstechnica.com/etc/books/deep-c.html
I liked a lot how you switch on count and loop on j. If gcc didn't comply, I would never notice it.
And even then it is a matter of experience. It looks odd to me to have multiline comments not in its own 'paragraph' of the code, so draws the eye right away. Perhaps this would foil some programmers, but not more than once, I'd have thought. In my experience, run-on compound statements are much more common and hard to intuitively spot:
Duff's device is difficult to understand from first principles, but even that is a bad example of unmaintainable code because a) it looks like nothing except Duff's device, you only need to see the pattern once or twice and you'd recognise it, and at least know 'it's that weird pattern for unrolling loops', and b) it is a performance optimisation that only belongs in code that is profiled and needs to go that fast. As such it should be well commented to avoid regressions by well meaning refactor-zealots. Inline assembly or heavy intrinsics are more difficult to read than regular C too, so you only use them when you need to. In my experience manual loop unrolling is very rarely needed.Although it should be noted that the original person to use Duff's device did admit that he tried everything else to optimize it and only that worked, and he never advocated that people should use it as a general optimization technique.
Can you say what kind of stuff and in what kinds of situations you unroll loops. Just out of curiosity.
As always, profiling is key.
Note that with gcc, you can reach the same results by using the 'indirect goto' that is both more powerful, and more dangerous! void * lab; lab = &my_label; goto *lab; my_label: ...
"The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined"
There is no guarantee on the order of the bits inside a bitfield. The compiler may also introduce padding, e.g. for alignment purposes. This makes bitfields unusable for unpacking binary data.
Unfortunately, you're stuck with shifting and masking to replicate the same effect.
The problem was that some bits in that register would be cleared automatically each time, so even if you wrote 0 it would read back as 1 the next time. Some other bit would always trigger an action if you wrote to it regardless if you wrote the same value as it had before, this was called the send_bit and when you wrote 0 it sent some stuff onto the network cable. So code that looked perfectly fine like this:
Actually sent 3 packets instead of 1 because the compiler translated each write of a bitfield member to a write of the whole register, some other bits in bitsa could get corrupted by the bitsb-write since they didn't read back as they were written. I assume the cpu had a minimum addressable unit of 8 bits so the compiler had to translate each line into something like register = (register | setbits) & clearbits; which requires reading the previous value each time just to write a single bit, this is very easy to overlook when you just see the three lines of code being written in a neat sequence.Most PCI/PCIe devices have memory mapped registers that behave similarly. Like DMA registers... Although it's a bit bad idea to trigger send on writing 0 bit to the corresponding bit in the register. But hardware memory mapped registers are weird and these things are common. Like writing 1-bit to clear.
So the problem was the fact that the language gives the impression of having more control than what the hardware is actually offering. In this case bit access must have been better left to platform-dependent libraries (when it would present itself as something more than what masks usage can do).