resmgr_msgread vs memcpy and safety;

I’m using memcpy() instead of resmgr_msgread() (or MsgRead())
in getting/setting data structures in my resmgr io_devctl()
(resmgr_io_funcs.devctl = io_devctl);

What is with safety in that situation ?
/memory errors, faults;

Can I use memcpy() instead of resmgr_msgread() ?
/do You have MsgRead() source code ?
is there any calls to memcpy() ?

“Q” <no@spam.pl> wrote in message news:edr4rh$itc$1@inn.qnx.com

I’m using memcpy() instead of resmgr_msgread() (or MsgRead())
in getting/setting data structures in my resmgr io_devctl()
(resmgr_io_funcs.devctl = io_devctl);

What is with safety in that situation ?
/memory errors, faults;

Can I use memcpy() instead of resmgr_msgread() ?
/do You have MsgRead() source code ?
is there any calls to memcpy() ?

MsgRead will make a kernel call to gather the unread portion of the message,
if it has not been already read. You cannot replace it with memcpy.

MsgRead will make a kernel call to gather the unread portion of the
message, if it has not been already read. You cannot replace it with
memcpy.

…so why it works ? :slight_smile:

“Q” <no@spam.pl> wrote in message news:edruhf$6np$1@inn.qnx.com

MsgRead will make a kernel call to gather the unread portion of the
message, if it has not been already read. You cannot replace it with
memcpy.

…so why it works ? > :slight_smile:

Most probably because the default msg size that is ready by the resmgr
framework is enough to contain the whole message. If the message would be
bigger then the buffer size your code would break.

Most probably because the default msg size that is ready by the resmgr
framework is enough to contain the whole message.

…so I can use memcpy() instead of MsgRead()
if I set resmgr attributes (in resmgr_attach()) to that:
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;
…and any received message is <= 2048 bytes length;

correct?

“Q” <no@spam.pl> wrote in message news:edt6dg$19r$1@inn.qnx.com

Most probably because the default msg size that is ready by the resmgr
framework is enough to contain the whole message.

…so I can use memcpy() instead of MsgRead()
if I set resmgr attributes (in resmgr_attach()) to that:
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;
…and any received message is <= 2048 bytes length;


correct?

Yes.

I don’t know how anyone else feels about this, but unless this
behavior is documented by QNX, it sounds like a really bad idea.

maschoen <maschoen@pobox-dot-com.no-spam.invalid> wrote:

I don’t know how anyone else feels about this, but unless this
behavior is documented by QNX, it sounds like a really bad idea.

I’m pretty sure that behaviour (pre-growing the receive buffer)
is documented and expected behaviour. At least, I teach it
reglarly. :wink:

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

Q <no@spam.pl> wrote:

Most probably because the default msg size that is ready by the resmgr
framework is enough to contain the whole message.

…so I can use memcpy() instead of MsgRead()
if I set resmgr attributes (in resmgr_attach()) to that:
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;
…and any received message is <= 2048 bytes length;

correct?

This assumption may broken if you receive a “combind message”
(multiple message in one shot).

-xtang

This assumption may broken if you receive a “combind message”
(multiple message in one shot).

I dont use combined messages,
so it would work :slight_smile:

thanks for advice!

I don’t know how anyone else feels about this, but unless this
behavior is documented by QNX, it sounds like a really bad idea.

I saw that (memcpy in io_devctl instead of resmgr read)
in network ddk;
/in pcnet, ne2000 (and others) driver sources!

I don’t know how anyone else feels about this, but unless this
behavior is documented by QNX, it sounds like a really bad idea.

so why in network cards drivers (I’ve got source code)
there is memcpy (to get/set message data),
instead of resmgr_msgread/resmgr_msgwrite ???