Hi,
I’m quite new to unix programming.
I’m writing a resource manager for a data acquisition card under Neutrino. I
would like to report an “signal out of range” condition from the resource
manager to the client by using the _RESMGR_STATUS macro.
The standard errno.h file that comes with Neutrino doesn’t have a
declaration for the particular error type ( and others I’m interest to ).
A possible kludge would be to edit the errno.h file and add few customs
errno definitions, to suit the particular application.
Would you suggest any more elegant solution ? What is the “normal” way of
doing this ? Just including an additional customerrno.h with the new
definitions ? Would this have any impact on the system ?
I’ll appreciate any comment / reading suggestion
Thanks a lot,
Andrea.
Andrea Borsic wrote:
Hi,
I’m quite new to unix programming.
I’m writing a resource manager for a data acquisition card under Neutrino. I
would like to report an “signal out of range” condition from the resource
manager to the client by using the _RESMGR_STATUS macro.
The standard errno.h file that comes with Neutrino doesn’t have a
declaration for the particular error type ( and others I’m interest to ).
What about ERANGE (error - out of range) ? Sounds like a fit to me.
A possible kludge would be to edit the errno.h file and add few customs
errno definitions, to suit the particular application.
Would you suggest any more elegant solution ?
Yes, if errno.h has a match, use it.
What is the “normal” way of
doing this ?
See below.
Just including an additional customerrno.h with the new
definitions ?
This is how I do it, not sure whether it’s normal or not 
Would this have any impact on the system ?
Just make sure error codes don’t overlap with the standard error codes,
and everything should be fine.
Rennie
Andrea Borsic <aborsic@brookes.ac.uk> wrote:
Hi,
I’m quite new to unix programming.
I’m writing a resource manager for a data acquisition card under Neutrino. I
would like to report an “signal out of range” condition from the resource
manager to the client by using the _RESMGR_STATUS macro.
The standard errno.h file that comes with Neutrino doesn’t have a
declaration for the particular error type ( and others I’m interest to ).
A possible kludge would be to edit the errno.h file and add few customs
errno definitions, to suit the particular application.
Would you suggest any more elegant solution ? What is the “normal” way of
doing this ? Just including an additional customerrno.h with the new
definitions ? Would this have any impact on the system ?
As Rennie sez in a later message, use the errno.h definitions where possible.
If you are controlling the resource manager using “devctl()” (or ioctl()),
then there’s a final argument which allows you to pass device-specific error
numbers and status information; that’s what I’d use in that case.
If it’s just a read() or write() that you’re trying to fail, then a generic
error would be ok, and then you can use devctl() to get the “specific”
error number, if that’s appropriate…
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Rennie Allen <rallen@csical.com> wrote:
Andrea Borsic wrote:
…
Just including an additional customerrno.h with the new
definitions ?
Would this have any impact on the system ?
Any program that uses strerror() or perror() to display an error message
will just say “Unknown error” (at least that’s what it says on my
machine). Not very useful.
Just make sure error codes don’t overlap with the standard error codes,
By “standard”, I guess you don’t mean POSIX or ISO C or anything like
that, do you?
I presume you mean “defined in the particular version of QNX that you’re
compiling for”, right?
and everything should be fine.
At least, everything will be fine until the next version of the OS.
You’ll need to check for an overlap every time you upgrade.
\
Wojtek Lerch QNX Software Systems Ltd.
Wojtek Lerch wrote:
By “standard”, I guess you don’t mean POSIX or ISO C or anything like
that, do you?
I presume you mean “defined in the particular version of QNX that you’re
compiling for”, right?
Yes. I should have quoted standard, as you did 
At least, everything will be fine until the next version of the OS.
You’ll need to check for an overlap every time you upgrade.
In practice you can leave a large gap, I haven’t been bitten yet…
Rennie
It would be nice it there were a define for USER_DEFINED_ERRORS where
anything above that was fair game not to be overwritten by both POSIX and
QNX. Better still would be a second level of QNX_ASSIGNED_3RD_PARTY_ERRORS
where vendors of third party software could be assign specific numbers and
have their text strings embedded into the strerror() strings (kind of like
traceinfo major numbers were assigned in QNX4).
Does POSIX allow for an OS vendor to provide this in a manner that POSIX
themselves will never ever, not even in a million years violate?
“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:a920cg$p77$1@nntp.qnx.com…
Rennie Allen <> rallen@csical.com> > wrote:
Andrea Borsic wrote:
…
Just including an additional customerrno.h with the new
definitions ?
Would this have any impact on the system ?
Any program that uses strerror() or perror() to display an error message
will just say “Unknown error” (at least that’s what it says on my
machine). Not very useful.
Just make sure error codes don’t overlap with the standard error codes,
By “standard”, I guess you don’t mean POSIX or ISO C or anything like
that, do you?
I presume you mean “defined in the particular version of QNX that you’re
compiling for”, right?
and everything should be fine.
At least, everything will be fine until the next version of the OS.
You’ll need to check for an overlap every time you upgrade.
\
Wojtek Lerch QNX Software Systems Ltd.
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:a9219s$2qd$1@inn.qnx.com…
It would be nice it there were a define for USER_DEFINED_ERRORS where
anything above that was fair game not to be overwritten by both POSIX and
QNX. Better still would be a second level of
QNX_ASSIGNED_3RD_PARTY_ERRORS
where vendors of third party software could be assign specific numbers and
have their text strings embedded into the strerror() strings (kind of like
traceinfo major numbers were assigned in QNX4).
Does POSIX allow for an OS vendor to provide this in a manner that POSIX
themselves will never ever, not even in a million years violate?
I think that would get complicate, there is also the strerror() to deal
with.
“Wojtek Lerch” <> wojtek_l@yahoo.ca> > wrote in message
news:a920cg$p77$> 1@nntp.qnx.com> …
Rennie Allen <> rallen@csical.com> > wrote:
Andrea Borsic wrote:
…
Just including an additional customerrno.h with the new
definitions ?
Would this have any impact on the system ?
Any program that uses strerror() or perror() to display an error message
will just say “Unknown error” (at least that’s what it says on my
machine). Not very useful.
Just make sure error codes don’t overlap with the standard error
codes,
By “standard”, I guess you don’t mean POSIX or ISO C or anything like
that, do you?
I presume you mean “defined in the particular version of QNX that you’re
compiling for”, right?
and everything should be fine.
At least, everything will be fine until the next version of the OS.
You’ll need to check for an overlap every time you upgrade.
\
Wojtek Lerch QNX Software Systems Ltd.
Mario Charest wrote:
I think that would get complicate, there is also the strerror() to deal
with.
I don’t see strerror() as being an issue. Obviously, generic applications will
report “Unknown error” (and that is not unreasonable for some sort of error
that doesn’t fall into a “standard” category). Applications specifically designed
for the particular resource manager will test the value of the error
return against the application specific errors known starting value, and
do an application specific decoding for errors with codes above that value).
But to re-iterate, one should always use an error code from errno where
the mapping is reasonable, in order to present useful error messages
(via strerror() to the widest possible audience).
Rennie
Mario Charest <goto@nothingness.com> wrote:
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:a9219s$2qd$> 1@inn.qnx.com> …
It would be nice it there were a define for USER_DEFINED_ERRORS where
anything above that was fair game not to be overwritten by both POSIX and
POSIX says nothing about the numeric values of error codes. The error
codes it defines are just symbolic names.
I don’t know how much agreement there is among all the various POSIX
systems about the actual values. If most of existing OSes use the same
numbers that we do, then I guess it might be hard to convince us to
pick a range and promise you that we’ll never put any error codes in
that range. If each OS defines its own set of values and we don’t care
about matching any one of them, it might be easier. But I don’t know
which is the case.
QNX. Better still would be a second level of QNX_ASSIGNED_3RD_PARTY_ERRORS
where vendors of third party software could be assign specific numbers and
have their text strings embedded into the strerror() strings (kind of like
traceinfo major numbers were assigned in QNX4).
I think that would be a bit excessive; but giving you a range of values
and promising that strerror() will report them as “User error #1”
through “User error #100” sounds like a good idea to me.
BTW: This is my personal opinion. Don’t consider it an official
response from QNX.
Does POSIX allow for an OS vendor to provide this in a manner that POSIX
themselves will never ever, not even in a million years violate?
Today’s version of POSIX doesn’t promise a lot about the next version of
POSIX, let alone the 1002002 version of POSIX.
But today’s version of POSIX says nothing about the actual numbers that
the errno codes map to, and there’s hope that things are going to stay
that way for a while.
\
Wojtek Lerch QNX Software Systems Ltd.
The concept of strerror() strings could be easily dealt with using something
like weak externs. Each vendor is given a block of say 64 errno numbers
starting at a 64 boundary. If my block starts at 1536 and my code generates
an error # 1539 then strerror() check for a non-NULL pointer to an array of
string pointers and returns the 4th pointer ( string_array[3] ).
BTW, does GCC support weak externs? I miss them from my old IBM days.
If so, how does one declare one?
“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:a92an9$30l$1@nntp.qnx.com…
Mario Charest <> goto@nothingness.com> > wrote:
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:a9219s$2qd$> 1@inn.qnx.com> …
It would be nice it there were a define for USER_DEFINED_ERRORS where
anything above that was fair game not to be overwritten by both POSIX
and
POSIX says nothing about the numeric values of error codes. The error
codes it defines are just symbolic names.
I don’t know how much agreement there is among all the various POSIX
systems about the actual values. If most of existing OSes use the same
numbers that we do, then I guess it might be hard to convince us to
pick a range and promise you that we’ll never put any error codes in
that range. If each OS defines its own set of values and we don’t care
about matching any one of them, it might be easier. But I don’t know
which is the case.
QNX. Better still would be a second level of
QNX_ASSIGNED_3RD_PARTY_ERRORS
where vendors of third party software could be assign specific numbers
and
have their text strings embedded into the strerror() strings (kind of
like
traceinfo major numbers were assigned in QNX4).
I think that would be a bit excessive; but giving you a range of values
and promising that strerror() will report them as “User error #1”
through “User error #100” sounds like a good idea to me.
BTW: This is my personal opinion. Don’t consider it an official
response from QNX.
Does POSIX allow for an OS vendor to provide this in a manner that
POSIX
themselves will never ever, not even in a million years violate?
Today’s version of POSIX doesn’t promise a lot about the next version of
POSIX, let alone the 1002002 version of POSIX.
But today’s version of POSIX says nothing about the actual numbers that
the errno codes map to, and there’s hope that things are going to stay
that way for a while.
\
Wojtek Lerch QNX Software Systems Ltd.