Void * Issues As Type Members And Function Return Types

[Peter_R]

I've recently started looking at BennuGD and got to the point where it would be convenient to have a linked list. So, I've tried to implement a generic linked list using void * for the stored items but this has led to a couple of issues.

Firstly, I couldn't get the code to compile with a type containing a void * element but I managed to work around this by first defining a type containing nothing by a void element. I have no idea why this worked and since the compiler error was a syntax / parsing error I can think of no good reason why this should work :S.

Secondly, I have not managed to successfully compile code that contains a function that returns a void * and I've tried an analogous work around to the above, defining a function returning type void, but that didn't work. Currently I'm working around this by returning an int * and doing some nasty type cast mangling but I don't think I should need to do this.

Has anyone else run into similar issues to these?

[SplinterGU]

please, sample code...

[Peter_R]

I'll post isolated test cases for each of the potential bugs within the next couple of hours. Thanks for replying so quickly.

[SplinterGU]

thanks you!

[Peter_R]

I've attached two files to this post:

• void_pointer_type.prg shows the manifestation of the first bug
• void_pointer_type_workaround.prg shows the suppression of the first bug via the workaround

I'll post a test case for the second bug in a little while.

[Peter_R]

I've attached another file which demonstrates the second bug. I believe it is possible that the same workaround cannot be applied in this case as it is not possible to get BennuGD to compile code that contains a function returning void.

[Peter_R]

I've attached another two files which demonstrate the first bug also affecting private variable declarations:

• void_pointer_private.prg shows the manifestation of the first bug
• void_pointer_private_workaround.prg shows the suppression of the first bug via the workaround

I think it is likely that this bug will affect any type of variable declarations. The workarounds for the different manifestations may also be effective at remedying all such manifestations and not just their respective versions.

[Peter_R]

I've discovered a third type of bug and have attached a test case. This bug manifests when a function is defined to take an argument of void * and is then called as such.

[Peter_R]

I've investigated a bit and found a workaround for the third type of bug, I'm attaching it to this post.

[SplinterGU]

oh, sorry, I'm stupid... "void" isn't a valid datatype for bennugd.

when you use "void" first time in the code, you are declared it as a process type named "void"... then works later... but "void" don't exists in bennugd

[SplinterGU]

when you define  Function voidPtrArgFunc(void *voidPtrArg)
you are define

Function voidPtrArgFunc(void, *voidPtrArg)

because void isn't a valid data type... it was defined automatly as a "process type" (int *).

[Peter_R]

I figured it was something like that, which explains why the work around technique doesn't apply to the second bug. I.e. creating a function that returns void doesn't allow me create a function returning void *.

However, if there is no type void is there also no type void *? What should I be using if I want to have a pointer to an arbitrary type? Such as the case where you would use a void * in C, for example.

[SplinterGU]

any type... a "int *" for example...

[SplinterGU]

I'll change the "feature" that allow declare arguments in a process/functions without comma...

[Peter_R]

I'd very much like to continue using BennuGD for my development but this is functionality I really require. This is so I don't have to do things like duplicate my linked list code for each type I want to create lists of etc.

I could do something such as always using an int *. Then I could add an explicit (int *) cast as I pass objects in and an explicity (arbitraryType *) cast as I get the objects back out, but this would make the code a lot messier.