Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Jose on August 31, 2004, 09:19:40 PM

Title: Where's da bug
Post by: Jose on August 31, 2004, 09:19:40 PM
if (!(buffertask = (MsgPort *)CreateProc(Buffertaskname, 0L, buffertaskSegList, 1000L)))
  {printf("coudn't create MDBuffer/n");
   unloadseg......}
.........
.......


I'm getting Error 76 identifier expected or something with VBCC..

By the way, do I really need to cast it (eg. (MsgPort *) ) ? I was getting another error before I added that. The variable holding the result (buffertask) is declared as struct MsgPort *buffertask so I can't see what was the problem.
Title: Re: Where's da bug
Post by: Slash on August 31, 2004, 09:25:07 PM
Should buffertask not be a "struct Process *" e.g.

struct Process *buffertask = NULL;

buffertask = (struct Process *)CreateNewProc(...)

That's how I create my new processes. I think CreateProc is obsolete now. Use CreateNewProc.
Title: Re: Where's da bug
Post by: Jose on August 31, 2004, 09:40:31 PM
@Slash

Yes, CreatePro is obsolete but I want the code to also conditionally run on 1.3 :-)

I tried it with a struc process instead and it seems to work.
I can't really say if it works because till now VBCC was outputting the errors then crashing. Now it's just crashing after I run it so I assume there are no errors left..(don't bother asnwering I'm gonna start a new thread about my VBCC crashes.)..
 
Title: Re: Where's da bug
Post by: Jose on August 31, 2004, 09:59:45 PM
I'm curious to know if it is really necessary to do the casting to struct *process when using CreatePro, or CreateNewProc...
In theory both should return that type so it shouldn't be necessary right?
Title: Re: Where's da bug
Post by: itix on August 31, 2004, 10:10:44 PM
Funny but my autodocs are saying that CreateProc() returns struct MsgPort * ...
Title: Re: Where's da bug
Post by: Karlos on August 31, 2004, 10:13:41 PM
Documentation error?

As far as I recall, CreateMsgPort() should return struct MsgPort*, not CreateProc().

In any event, CreateNewProc() is a bit more useful IMHO.
Title: Re: Where's da bug
Post by: Jose on August 31, 2004, 10:23:09 PM
@itix

Ahh, yes!
Mine too!
So that's probably why casting is needed
Title: Re: Where's da bug
Post by: Jose on August 31, 2004, 10:29:26 PM
Hmm, I checked the structures and the Process structure starts with a task structure followed by the MsgPort.
CreateProc returns the MsgPort according to the docs, so I think if I cast it fo a Process it's an error. Should be a MsgPort after all. Which brings me back to my first error(first post)!!
Title: Re: Where's da bug
Post by: itix on August 31, 2004, 10:30:16 PM
Quote
Documentation error?

As far as I recall, CreateMsgPort() should return struct MsgPort*, not CreateProc().

It is funny but looks intentional. Even my good old RKRM: Includes and Autodocs is saying CreateProc() returns struct MsgPort *.
Title: Re: Where's da bug
Post by: Karlos on August 31, 2004, 10:38:52 PM
Quote

Jose wrote:
Hmm, I checked the structures and the Process structure starts with a task structure followed by the MsgPort.
CreateProc returns the MsgPort according to the docs, so I think if I cast it fo a Process it's an error. Should be a MsgPort after all. Which brings me back to my first error(first post)!!


If you cast any struct X* to struct Y* and the first member struct X is not an object of type struct Y, then the cast is badly broken. You need to account for the offset of struct Y within the struct X.

I don't see that a struc MsgPort* pointer is safely castable to struct Process* unless you absolutely know for a fact that the MsgPort structure pointed to is really a member of a Process. Even then you will have to do some pointer arithmetic (or use offsetof()) to properly determing the address of the Process structure within which your MsgPort object is situated.
Title: Re: Where's da bug
Post by: Karlos on August 31, 2004, 10:47:26 PM
Checked the RKMs and it does indeed return struct MsgPort* :-o

It also says that it creates a struct Process and returns it's message port.

So, I'd suggest the following dodgyness to obtain the address of the Process structure within which the MsgPort resides:

#include /* for offsetof() macro */

UBYTE* portAddr = (UBYTE*)CreateProc(.....); /* UBYTE for simple pointer arithmetic */

struct Process* process = (struct Process*)(portAddr - offsetof(struct Process, pr_MsgPort));

Title: Re: Where's da bug
Post by: itix on August 31, 2004, 10:53:18 PM
Quote
if (!(buffertask = (MsgPort *)CreateProc(Buffertaskname, 0L, buffertaskSegList, 1000L)))

Your casting is wrong. It should be (struct MsgPort *), just (MsgPort *) alone is nothing and VBCC complains.

And, do you have:

struct Process *buffertask;

?

If so, it is broken because it is not returning struct Process *...
Title: Re: Where's da bug
Post by: Jose on September 01, 2004, 01:03:55 AM
@itix
yes, silly me....forgot to add the type "struct"  to the cast... 8-)
Title: Re: Where's da bug
Post by: Jose on September 01, 2004, 01:30:34 AM
@Karlos

Usefull. Shouldn't that be a long instead of a byte?
Title: Re: Where's da bug
Post by: Piru on September 01, 2004, 03:09:08 AM
This struct MsgPort * return value is some good'ol BCPL legacy. BCPL CreateProc returns this, and so does the old dos function.

Actually BCPL considered address of Process' pr_MsgPort to be "process pointer" rather than 'struct Process *'. Processes were referenced by their pr_MsgPort address, too. Also address of various other pr_#? fields were calculated relative to pr_MsgPort, which gave some rather funky negative or positive offsets.
Title: Re: Where's da bug
Post by: Piru on September 01, 2004, 03:15:31 AM
Quote
Shouldn't that be a long instead of a byte?

No, it must be byte. If it was long, the ptr artith calculations would be *sizeof(long).

You're obviously mixing it with (SOMEPTRTYPE) (((ULONG) x) + y). Using (UBYTE *) or (char *) is better since it will work correctly regardless of arch pointer size (as if amigaos or compats would ever go 64bit. AROS could in theory, assuming all ptr arith uses IPTR and that taglists can cope 64bit values. AROS wisely introduced IPTR type, which always is able to represent pointer as ingeter, and this must be used in ptr arith instead of ULONG).

Anyway it's good style not to assume pointer size, at least if you write semi-portable code.