Casting void * to enum

I’m trying to port some existing code over to RISC OS and it’s failing when trying to cast a void * to an enum. This is a bit outside my knowledge; I try to avoid void * whenever possible so I’m not sure what exactly is going on here.

Here’s a little code sample:

typedef enum Pet
{
    Cat = 0,
    Dog = 1,
    FiligreeSiberianHamster = 2
} Pet;

int main(void)
{
    void *temp = (void *)Cat;
    Pet mypet = (Pet)temp;
    return 0;
}

This works fine in Xcode on my Mac, and presumably also works in GCC and Microsoft’s compiler (I haven’t tested them but the docs list them as compatible). However, when using the DDE, I get “illegal cast to ‘enum Pet’”.

In a pinch I could get rid of the void * completely and replace it with a true Pet object, but I’d rather not fiddle with the original code too much if I can help it.

Does anyone know whether there’s a trick to getting this working?

Setting UNIX pcc ‘downgrades’ the Serious error to a Warning.

HTH.

I may be wrong here, but…

You have defined an integer with a set of named values (the enum).
You are creating a pointer to an object (temp).
You are placing into that pointer, a pointer to an integer of value zero. Remember, when you see a ‘*’, that indicates that there is no actual variable here, just a name that will end up referring to something else somewhere else.
Then you are assigning to an integer the value of a pointer to an integer of value zero.

I think that’s what is happening here, because temp is not being dereferenced, so it’s actually trying to pass back the pointer, the address of the thing, rather than the value of the thing.
I find the code to be overcomplicating things, however, does Pet mypet = (Pet *)temp; work?
The whole thing just looks like it has “implementation defined” written all over it.

Setting UNIX pcc ‘downgrades’ the Serious error to a Warning.

Aha, “my code worked fine in the sixties and I have no truck with this newfangled nonsense”

Setting UNIX pcc ‘downgrades’ the Serious error to a Warning.

Aha, “my code worked fine in the sixties and I have no truck with this newfangled nonsense”

Except that gcc shows neither error nor warning.

Setting UNIX pcc ‘downgrades’ the Serious error to a Warning.

Thanks! I’ll read about that :)

The whole thing just looks like it has “implementation defined” written all over it.

I can certainly see where you’re coming from, but according to the docs the original code is compatible with not only GCC and Visual C++, but also whatever compilers are used for OS/2 and classic Mac OS. If it is implementation-defined then it seems that all these implementations are doing the same thing.

I find the code to be overcomplicating things

You should see what it looked like before I condensed it down to the minimum to make it fail!

however, does Pet mypet = (Pet *)temp; work?

Nope. Same error in DDE, and Xcode doesn’t like it either. Xcode suggests Pet mypet = *(Pet *)temp; which compiles, but then crashes when run.

Aha, “my code worked fine in the sixties and I have no truck with this newfangled nonsense"

Hey, it’s only from 1998 :P

You have defined an integer with a set of named values (the enum).
You are creating a pointer to an object (temp).
You are placing into that pointer, a pointer to an integer of value zero. Remember, when you see a ‘*’, that indicates that there is no actual variable here, just a name that will end up referring to something else somewhere else.

It might be that I don’t understand your explanation, but I think you’re wrong.

void *temp = (void *)Cat;

The value being stored in *temp by this is zero: it’s not a pointer to a zero value, it is the zero value itself. This means that *temp is now a NULL pointer, although that’s not actually an issue here.

Then you are assigning to an integer the value of a pointer to an integer of value zero.

Again, no.

Pet mypet = (Pet)temp;

Here, that zero pointer in *temp is being turned back into an integer. Not the value pointed to by the pointer, but the actual pointer value itself.

The problem is that C doesn’t offer a void type to allow “any value” to be stored in a variable. It does offer a void*, which is a pointer to an object of any type, and the temptation to abuse this can sometimes be there. In effect, this code is crowbarring an enum value into a void * pointer – presumably because that void * pointer is there, being made available by some library code.

The whole thing just looks like it has “implementation defined” written all over it.

I don’t think it does, but it’s certainly not “good” code.

It’s hard to say without seeing the original code, but this looks like a classic case of trying to abuse a void * offered by a library to hold an integer value. It’s quite a common temptation with libraries doing event driven stuff (eg. a Wimp dispatcher), because often these allow the client to supply a void * value which will be passed as a parameter to any callback functions: the idea, generally, is to use this to pass a pointer to a structure of the client’s choosing. If there’s only a single value, why not pass it directly¹?

If I’m correct, what the library would be expecting would be something like this:

typedef enum Pet
{
    Cat = 0,
    Dog = 1,
    FiligreeSiberianHamster = 2
} Pet;

struct state_block
{
    Pet my_pet;

    /* ... and any other related info. */
};

int main(void)
{
    struct state_block state;
    state.my_pet = Cat;

    void *temp = &state;
    Pet mypet = temp->my_pet;

    return 0;
}

This might seem a very contrived way of doing things, and in this example it is, but it seems to be a common approach in a lot of event driven code – and in the vast majority of cases, it does exactly what is required.

¹ The answer to that rhetorical question, by the way, is because when one thinks about it in more detail, it’s invariably not the correct solution to the problem.

Just giving Steve’s response a “+1”. Whilst I tend to avoid void* as much as possible, I encounter/deal with them quite frequently as I use RISC_OSLib. This uses void* for the purposes Steve mentioned – many event handler or alarm type functions allow you to set a trigger, and then specify a variable or structure to be passed to the handler function as a void*. Typically this might be the wimp event structure.

IIRC I had a similar problem to Chris when working on LockScreen recently, but I worked around it another way. Just can’t remember the exact details, and I have a feeling it was a compiler warning not a serious error. Fuzzy Sunday-monring brain.

Typically this might be the wimp event structure.

In my experience, it would be an application-specific pointer to some kind of internal struct. For example, in a multi-file (and hence multi-window) editor, you might have an instance of a struct for each window that’s open, holding all of its details. The Wimp event structure would be passed to the callback as a separate parameter.

I don’t use RISC_OSLib (instead using my own library and OSLib), but here’s a piece of typical code¹ that handles drag events within a window (there’s similar in the likes of CashBook and Locate):

First, we have a function which is called to start the drag operation. This will very likely get called from the Mouse_Click event handler, which will have ensured that the *handle parameter points to the application’s data block for the window that we are interested in. Generally, in my code, these blocks contain the Wimp’s window handle amongst other things, so there’s enough detail to get the drag started.

static void drag_select(struct results_window *handle, /* ... etc. */)
{
    wimp_drag drag;

    if (handle == NULL)
        return;

    drag.w = handle->window;
    drag.type = wimp_DRAG_USER_RUBBER;

    /* Do whatever else is required to set up the drag operation, then start
     * it by calling Wimp_DragBox.
     */

    wimp_drag_box_with_flags(&drag, wimp_DRAG_BOX_KEEP_IN_LINE | wimp_DRAG_BOX_CLIP);

    /* Tell our event dispatcher that when a User_Drag_Box event arrives,
     * it should call drag_end_handler() and pass it the handle (ie. pointer
     * to a structure which holds the details of the current window) that we
     * have been using here.
     */
 
    event_set_drag_handler(drag_end_handler, NULL, handle);
}

Next, the callback function, which the event dispatcher calls when the Wimp sends the User_Drag_Box event. It takes the data block from Wimp_Poll (as *drag), and the void * value that the previous function passed to the library when it called event_set_drag_handler(). This is immediately turned back into a pointer to a struct results_window, and is then used to identify the window that the drag just took place in.

static void drag_end_handler(wimp_dragged *drag, void *data)
{
    struct results_window *handle = data;
    
    if (handle == NULL)
        return;       

    /* Now do whatever we need to do to end the drag operation,
     * using the details that are in the supplied struct results_window.
     */
}

We’re drifting from the original question, but this might provide some context as to why a void * is often available to be abused as Chris describes.

¹ In my experience, at least.

It’s complaining because you’re casting a void* to an enum. But it’s perfectly legal to cast a void* to an int, and it’s also legal to cast an int to an enum. So:

Pet mypet = (Pet)(int)temp;

Thanks, Jeffrey. That actually crossed my mind after I’d gone to bed. I haven’t tried it yet, but it sounds like it’ll do the trick! :)

but I think you’re wrong.

Ah, yes. It needs the & for the address doesn’t it? <facepalm>

At any rate, it’s coercing an integer into something that normally holds an address, then back again.
It’s weird code.

The whole thing just looks like it has “implementation defined” written all over it.

I don’t think it does, but it’s certainly not “good” code.

Ask yourself what happens on a platform where sizeof address != int (assuming enum is int, that in itself is an implementation specific issue; the compiler could choose signed short and it would still work).

some context as to why a void * is often available to be abused

Yes, it’s the “I don’t care what the data type is” option.
Though I can’t help but think some explicit casting could get rid of the void…

But it’s perfectly legal to cast a void* to an int, and it’s also legal to cast an int to an enum.

Whoo! Loophole abuse! ;-)

Which is why we have intptr_t

I haven’t tried it yet, but it sounds like it’ll do the trick! :)

I’ve just tried it and can confirm that it works. Thanks again!