Pointer arguments philosophy

Hi,

I am thinking about the philosophy of pointer arguments to functions.

E.g.

TimerCreate( clockid_t id, const struct sigevent* event )

Will TimerCreate() reference the event structure after it has been called?
Or will it setup a local copy of the event structure?

There are a lot other functions where I’m also not sure weather the OS will
reference provided arguments or not. E.g. the attr parameter of
message_attach().

Will the following example work?

my_message_attach( void* handle )
{
message_attr_t attr;
attr.flags = 0;
attr.nparts_max = 1;
attr.msg_max_size = 1024;
return message_attach( …, attr, … );
}

Regards
Peter

“Peter Stöckigt” <stoeckigt.p@stn-atlas.de> wrote:

Hi,

I am thinking about the philosophy of pointer arguments to functions.

E.g.

TimerCreate( clockid_t id, const struct sigevent* event )

I would strongly suggest using the POSIX timer_create() call,
rather than the underlying kernel call, TimerCreate(). In general,
choosing the most portable/standard equivalent API is usually to
your benefit.

Will TimerCreate() reference the event structure after it has been called?
Or will it setup a local copy of the event structure?

Actually, it will create a kernel object, identified by the return value
that is initialized according to the passed in clock type and event
structure.

The “const” states that it will not change the value.

In most cases, a structure passed into a routine will be looked at
(and possibly changed depending on the const-ness of it) only while
the function is running, and will not be used thereafter. There are
exceptions, and these are generally documented as the exception.
(e.g. the macros SETIOV() or PtSetArg().)

There are a lot other functions where I’m also not sure weather the OS will
reference provided arguments or not. E.g. the attr parameter of
message_attach().

Will the following example work?

Yes, it will work fine.

my_message_attach( void* handle )
{
message_attr_t attr;
attr.flags = 0;
attr.nparts_max = 1;
attr.msg_max_size = 1024;
return message_attach( …, attr, … );
}

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

“David Gibbs” <dagibbs@qnx.com> schrieb im Newsbeitrag
news:b5net1$2ui$4@nntp.qnx.com
“Peter Stöckigt” <stoeckigt.p@stn-atlas.de> wrote:

Hi,

I am thinking about the philosophy of pointer arguments to functions.

E.g.

TimerCreate( clockid_t id, const struct sigevent* event )

I would strongly suggest using the POSIX timer_create() call,
rather than the underlying kernel call, TimerCreate(). In general,
choosing the most portable/standard equivalent API is usually to
your benefit.

Will TimerCreate() reference the event structure after it has been called?
Or will it setup a local copy of the event structure?

Actually, it will create a kernel object, identified by the return value
that is initialized according to the passed in clock type and event
structure.

The “const” states that it will not change the value.

In most cases, a structure passed into a routine will be looked at
(and possibly changed depending on the const-ness of it) only while
the function is running, and will not be used thereafter. There are
exceptions, and these are generally documented as the exception.
(e.g. the macros SETIOV() or PtSetArg().)

There are a lot other functions where I’m also not sure weather the OS
will
reference provided arguments or not. E.g. the attr parameter of
message_attach().

Will the following example work?

Yes, it will work fine.

my_message_attach( void* handle )
{
message_attr_t attr;
attr.flags = 0;
attr.nparts_max = 1;
attr.msg_max_size = 1024;
return message_attach( …, attr, … );
}

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Sorry, I need to get my newsreader under control.
The previous posting is just a copy of what David posted.

Back to the topic:

Thank you for the hints. I will watch out for the most portable API.

The “const” states that it will not change the value.

Sure, but it does not state that it will not be referenced later on.

In most cases, a structure passed into a routine will be looked at
(and possibly changed depending on the const-ness of it) only while
the function is running, and will not be used thereafter. There are
exceptions, and these are generally documented as the exception.
(e.g. the macros SETIOV() or PtSetArg().)

This helps, thank you.

Regards
Peter