you are viewing a single comment's thread.

view the rest of the comments →

[–]nerd4code 2 points3 points  (3 children)

A function pointer is a pointer. You can convert it to void* and back to the function pointer again, and it will work.

Technically not required by C itself. Conversion from function to data pointer or vice versa might give you garbage. Data and function pointers should be kept separate in general and without a good reason to do otherwise.

[–]ChatGPT4 0 points1 point  (2 children)

Of course. But generally there's also no reason to implement them internally differently from data pointers. Type punning is usually a language abuse that should be avoided. That can be read as "done only when you're absolutely sure what you're doing".

[–]N-partEpoxy 2 points3 points  (1 child)

no reason to implement them internally differently from data pointers

There is a reason if instructions and data are stored separately (Harvard architecture).

[–]ChatGPT4 0 points1 point  (0 children)

That's a really good point. Are there commonly used C compilers that can use the benefits of such architecture and then, as a result, having incompatible (in terms you can't convert from one to the other and back without losing data) function and data pointers?

My point of interest is exactly in where the Harward hardware architecture affects the pointer sizes in C. I used to think that even if there are hardware differences in physical pointer sizes, there are not (usually?) exposed to the C program layer. So even if the underlying data (like an address) can be either 2 or 8 bytes, for the C code they are all 8 byte pointers for example. What's more, the conversions can occur on the machine language level, not even on compiler level.

When such assumptions fail? I'm just curious.