Hi,
I have ported recently an application that defines a private routine
with the name ‘MsgSend’ 
. This created a curious ‘concurrency’ to
a single threaded application every time when e.g. fgets() was
called.
At the first look the a call of fgets() produced a SIGSEGV … a
second look shows that the private MsgSend procedure was called in
the context of the fgets() call before the abort happens.
OK … fgets() is using internally MsgSend of QNX6.1, but why is
this implementation detail visible at link time??
And why doesn’t have the names of the kernel calls a prefix like
NTO_ ??
Armin
Armin Steinhoff <a-steinhoff@web._de> wrote:
At the first look the a call of fgets() produced a SIGSEGV … a
second look shows that the private MsgSend procedure was called in
the context of the fgets() call before the abort happens.
That’s correct behaviour. If you created a function called brk(), then
a call to malloc will most likely fail as malloc uses brk() to chance
the amount of space allocated.
OK … fgets() is using internally MsgSend of QNX6.1, but why is
this implementation detail visible at link time??
Since QNX is philosophy of QNX is message based services, this of
course natural. I’m not sure what you meant by “implementation detail
[being] visible”. This behaviour when you’re writing C programs will
occur under numerous other compilers (GCC in this case). This is a feature
and not a bug, as if you wanted to override some basic library service that
had a bug, or you wanted to implement more debugging information like for
malloc, this type of override is very useful.
-Adam
amallory@qnx.com
Operating System for Tech Supp wrote:
Armin Steinhoff <a-steinhoff@web._de> wrote:
At the first look the a call of fgets() produced a SIGSEGV … a
second look shows that the private MsgSend procedure was called in
the context of the fgets() call before the abort happens.
That’s correct behaviour. If you created a function called brk(), then
a call to malloc will most likely fail as malloc uses brk() to chance
the amount of space allocated.
OK … fgets() is using internally MsgSend of QNX6.1, but why is
this implementation detail visible at link time??
Since QNX is philosophy of QNX is message based services, this of
course natural. I’m not sure what you meant by “implementation detail
[being] visible”.
I mean you can change the implementation of a libray call by
replacing the kernel calls
used in that implementation … sounds flexible but it’s too
dangerous, IMHO.
This behaviour when you’re writing C programs will
occur under numerous other compilers (GCC in this case). This is a feature
and not a bug, as if you wanted to override some basic library service that
had a bug, or you wanted to implement more debugging information like for
malloc, this type of override is very useful.
Yes … but this type of overriding could happen by chance if there
is not a
name convention (as used with QNX4).
‘MsgSend’ is really a trivial name … and everyone who build a send
procedure could
get the idea to call it ‘MsgSend’. ‘QNX_MsgSend’ would be better
…
Armin
-Adam
amallory@qnx.com
Armin Steinhoff <a-steinhoff@web._de> wrote:
I mean you can change the implementation of a libray call by
replacing the kernel calls
used in that implementation … sounds flexible but it’s too
dangerous, IMHO.
You can do this with any library call (ie the malloc example from
the previous post). It is extremely flexible, and you’re right
you can shoot youself in the foot if you’re not careful about
how you use the namespace. But that’s the “thing” about C -
you can shoot yourself in the foot, if you require more advanced
namespace management, C++ has an “ok” implementation.
-Adam
amallory@qnx.com