The QNX Library Reference includes a gigantic table that summarizes the
“safety” information for all of the functions (e.g. can I call this function
from an interrupt handler, a signal handler, and so on). The documentation
for each function has its own “safety” table.
Is the large summary table useful to you as a developer? Do you use it, or
do you just refer to the table for each function that you want to use?
Thanks for any feedback.
Steve Reid <stever@qnx.com> wrote:
The QNX Library Reference includes a gigantic table that summarizes the
“safety” information for all of the functions (e.g. can I call this function
from an interrupt handler, a signal handler, and so on). The documentation
for each function has its own “safety” table.Is the large summary table useful to you as a developer? Do you use it, or
do you just refer to the table for each function that you want to use?
I think it would be more useful to just have separate lists of functions
that are interrupt-safe; signal-safe; and thread-unsafe (i.e. just
list the minorities).
–
Wojtek Lerch QNX Software Systems Ltd.
“Steve Reid” <stever@qnx.com> wrote in message
news:a75553$6e6$1@nntp.qnx.com…
The QNX Library Reference includes a gigantic table that summarizes the
“safety” information for all of the functions (e.g. can I call this
function
from an interrupt handler, a signal handler, and so on). The
documentation
for each function has its own “safety” table.Is the large summary table useful to you as a developer? Do you use it,
or
do you just refer to the table for each function that you want to use?
Are you looking for our blessing to take it out, lol!
Personnaly I’ve never used the table, I look at the doc of the function.
What might be helpfull is a list of unsafe function.
Thanks for any feedback.
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
People should also be aware that ANY function thatuses static data is
probibly unsafe to be called from signals, threads and ISR’s.
This includes functions that you write yourself.
Also, if you think you have a handle on the situation, MAKE SURE that your
static data is defined as volatile.
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Mario Charest” <goto@nothingness.com> wrote in message
news:a75ch7$6ob$1@inn.qnx.com…
“Steve Reid” <> stever@qnx.com> > wrote in message
news:a75553$6e6$> 1@nntp.qnx.com> …
The QNX Library Reference includes a gigantic table that summarizes the
“safety” information for all of the functions (e.g. can I call this
function
from an interrupt handler, a signal handler, and so on). The
documentation
for each function has its own “safety” table.Is the large summary table useful to you as a developer? Do you use it,
or
do you just refer to the table for each function that you want to use?
Are you looking for our blessing to take it out, lol!Personnaly I’ve never used the table, I look at the doc of the function.
What might be helpfull is a list of unsafe function.
Thanks for any feedback.
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Agree with Mario, These sort of huge tables are quite unusable. Function
by function infos are absolutely necessary. Maybe list of unsafe
functions could be interesting if it’s short!
cheers,
Alain
Steve Reid wrote:
The QNX Library Reference includes a gigantic table that summarizes the
“safety” information for all of the functions (e.g. can I call this function
from an interrupt handler, a signal handler, and so on). The documentation
for each function has its own “safety” table.Is the large summary table useful to you as a developer? Do you use it, or
do you just refer to the table for each function that you want to use?Thanks for any feedback.
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
: Agree with Mario, These sort of huge tables are quite unusable. Function
: by function infos are absolutely necessary. Maybe list of unsafe
: functions could be interesting if it’s short!
That’s what I suspected. The huge table is a pain to keep up-to-date, and
taxes our doc tools. If it’s useful, we’ll keep it (it sounds trite, but
your needs are more important than our convenience). If the huge table
isn’t useful, I’d be glad to delete it.
Any other comments?
(If it’s useful, we’ll keep it (it sounds trite, but your needs are more
important than our convenience).
Halleliua
If the huge table isn’t useful, I’d be glad to delete it.
Any other comments?
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Hi Steve
Personally, I can’t see the need for the huge table. As a programmer I have
never found the need to ask myself “What functions can/can’t I use here”. I
do find myself asking, “I want to use the function. Is it allowed here or
not?” So as long as the info is at the bottom of each function page, then I
think that’s all you need.
Yet I have no doubt that someone will disagree.
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Steve Reid” <stever@qnx.com> wrote in message
news:a7cpqh$12n$1@nntp.qnx.com…
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
: Agree with Mario, These sort of huge tables are quite unusable. Function
: by function infos are absolutely necessary. Maybe list of unsafe
: functions could be interesting if it’s short!That’s what I suspected. The huge table is a pain to keep up-to-date, and
taxes our doc tools. If it’s useful, we’ll keep it (it sounds trite, but
your needs are more important than our convenience). If the huge table
isn’t useful, I’d be glad to delete it.Any other comments?
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Bill Caroselli <qtps@earthlink.net> wrote in article <a7daur$33p$1@inn.qnx.com>…
Hi Steve
Personally, I can’t see the need for the huge table. As a programmer I have
never found the need to ask myself “What functions can/can’t I use here”. I
do find myself asking, “I want to use the function. Is it allowed here or
not?” So as long as the info is at the bottom of each function page, then I
think that’s all you need.Yet I have no doubt that someone will disagree.
I 100% agree 
I always avoid the huge tables and other unreachable for me stuff.
–
Eduard.
ed1k at yahoo dot com
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Steve Reid” <> stever@qnx.com> > wrote in message
news:a7cpqh$12n$> 1@nntp.qnx.com> …
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
: Agree with Mario, These sort of huge tables are quite unusable. Function
: by function infos are absolutely necessary. Maybe list of unsafe
: functions could be interesting if it’s short!That’s what I suspected. The huge table is a pain to keep up-to-date, and
taxes our doc tools. If it’s useful, we’ll keep it (it sounds trite, but
your needs are more important than our convenience). If the huge table
isn’t useful, I’d be glad to delete it.Any other comments?
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Steve Reid wrote:
Any other comments?
I haven’t seen anyone claim a big table containing a list of safe
functions is useful. I agree. A few people have mentioned that
a table (huge or otherwise) of UNSAFE functions would be useful.
I strongly believe this to be true. Such a table could be useful
for driving part of a software audit.
–
Kirk Bailey
Before you included the safty info at the bottom of each function the table
was useful because it was the ONLY place to go.
Without having checked, I’m guessing that just about half the function are
safe and half aren’t. So, I’m guessing, that neither side is much smaller
than the other.
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Kirk Bailey” <c23kab@eng.delcoelect.com> wrote in message
news:3C9B23EA.760C18D3@eng.delcoelect.com…
Steve Reid wrote:
Any other comments?
I haven’t seen anyone claim a big table containing a list of safe
functions is useful. I agree. A few people have mentioned that
a table (huge or otherwise) of UNSAFE functions would be useful.
I strongly believe this to be true. Such a table could be useful
for driving part of a software audit.–
Kirk Bailey
Bill Caroselli <qtps@earthlink.net> wrote:
: Before you included the safty info at the bottom of each function the table
: was useful because it was the ONLY place to go.
: Without having checked, I’m guessing that just about half the function are
: safe and half aren’t. So, I’m guessing, that neither side is much smaller
: than the other.
Here are a few numbers, thanks to grep and wc:
Cancellation point 362 859 0 9
Interrupt handler 220 1003 0 7
Signal handler 407 814 2 7
Thread 1106 120 0 4
The two N/A entries for the signal handler are abort() and _exit().
Functions that are documented together and have the same safety information
are counted once in the table above. There are 1230 safety tables currently
in the docs, plus the monster summary table.
Steve Reid <stever@qnx.com> wrote:
Here are a few numbers, thanks to grep and wc:
Yes No N/A See Caveats
Cancellation point 362 859 0 9
Interrupt handler 220 1003 0 7
My vote is that a list of 220 interrupt-safe functions is more useful
than a list of 1003 interrupt-unsafe functions.
BTW I must say 220 is much more than I expected. I’m surprised that
functions like chroot(), confstr(), gethostname(), modem_read(),
sethostname(), and sigblock() are interrupt-safe. Maybe some of those
are mistakes?
And I really don’t think the list of functions that we OFFICIALLY
APPROVE for use in interrupt handlers should contain such functions as
alloca(), alphasort(), basename(), bsearch(), cmdfd(), crypt(),
dn_comp(), dn_expand(), fnmatch(), hstrerror(), inet…(), isalpha()
and friends, rand(), regerror(), the various RESMGR… macros,
sigaddset() and friends, sigmask(), srand(), strcasecmp() and all the
other locale-sensitive functions, strcoll(), vsnprintf() (how come
snprintf() isn’t interrupt-safe?) – just to name a few…
Signal handler 407 814 2 7
Thread 1106 120 0 4The two N/A entries for the signal handler are abort() and _exit().
Why? According to POSIX, _exit() is signal-safe and abort() is not.
–
Wojtek Lerch QNX Software Systems Ltd.
“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:a7foeg$921$1@nntp.qnx.com…
Steve Reid <> stever@qnx.com> > wrote:
Here are a few numbers, thanks to grep and wc:
Yes No N/A See Caveats
Cancellation point 362 859 0 9
Interrupt handler 220 1003 0 7My vote is that a list of 220 interrupt-safe functions is more useful
than a list of 1003 interrupt-unsafe functions.I second Wojtek’s opinion.
Leon.
Leon Woestenberg <leon.woestenberg@gmx.net> wrote:
: I second Wojtek’s opinion.
Based on everyone’s comments, I think the most useful approach is to list the
functions that:
Thanks to everyone for the feedback.