Diagnosing Server Problems?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
61

<camz@passageway.com> wrote in message news:b603pr$qb1$1@inn.qnx.com…

Igor Kovalenko <> kovalenko@attbi.com> > wrote:
[snip]
If any change in QNX makes a previously working code (library call) to
fail,
for users that’s a failure of the library call.

I would normally agree with you, but in this case you are wrong. Armin is
using a library call incorrectly, the documentation says it will not work
with address ranged >4G, and Armin assumed that the MMU would never
generate
an address above that on a system with less than that memory. THAT is not
a valid assumption.

What happened to Armin is simple, he used an library function wrong, and
he
got lucky that on previous versions of QNX6, the library function was
technically “broken” in that it never returned values >4G. It’s fixed and
now it does. The result is that Armin’s broken code no longer works, and
his luck has run out.

This is NO DIFFERENT than writing code that uses shared memory but without
properly using semaphores. It will typically run perfectly fine on a
single
processor machine, and then crap out on an SMP machine. It’s NOT the SMP
machine that is broken, it’s the code. This is no different.

Actually it is a very bad analogy. Unprotected access to shared memory is
plain wrong because it is against the common logic. Using mmap() the way
Armin did is problematic, but does not conflict with the logic. Since QNX
never before supported address spaces >4Gb, it was pretty much guaranteed to
work. POSIX does not say anything on much of the details of mmap()
functionality, so what happens in practice is that you choose a certain way
to implement it, based on common implementations. Once you have chosen a
way, it becomes part of OS behavior your customers rely upon, just like all
the proprietary interfaces the OS in question has. Then it becomes a legacy
that you’re bound to support.

I DO NOT expect QSS to document all the case where “improper code
would
work prior to us fixing this bug”. Sure, they changed/improved the
functionality
and I expect them to document that… but not the fact that BAD CODE used
to
work as a SIDE EFFECT of the previous buggy behavior of that library
function.

If they had to document all the instances where a bug of theirs would
allow
a programmer to “get away with” bad code, and then document again when
they
fixed (and therfore broke the bad code) function… that’s lunacy.

I disagree. It has nothing to do with lunacy. It has to do with respect to
customers’ codebase and protection of their investments. Of course QNX can’t
anticipate every way to abuse the API, but they can and they should detect
and document all changes in behavior of API functions, no matter if the
change is from bad to good or the other way around. It is easily doable
using automated test procedures. It would cost QNX pretty small resources to
do that, whereas it could potentially cost much more for customers to find
bugs in the code that is considered working & stable. Changing that code can
be prohibitively costly when issues like formal validation/approval by
regulatory bodies are involved.

– igor

62

Igor Kovalenko <kovalenko@attbi.com> wrote:

Actually it is a very bad analogy. Unprotected access to shared memory is
plain wrong because it is against the common logic.

I used shared memory as an example becuase failing to use proper access
methods (semaphore, mutex, condvar, etc) is a very common mistake. It is
not common logic to most programmers (admittedly BAD/POOR programmers).
It is the sole reason why the proper use of threads is problematic, YOU
aren’t a bad programmer, and you’ve learnt the proper way to deal with
shared memory, once you have learnt the proper way (and why it has to be
done that way), it seems to defy logic that others would not inherintly
understand it.

Sad reality is that there are more bad / poor programmers out there than
good ones, and they are constantly making such mistakes (as well as
pointer mistakes, and memory leaks, etc).

Using mmap() the way Armin did is problematic, but does not conflict
with the logic. Since QNX never before supported address spaces >4Gb,
it was pretty much guaranteed to work.

Igor… come on… that’s just a bad assumption. The best rule of thumb
is that if a certain behaviour is NOT documented that you are taking
a risk in “trusting” that the behaviour will remain the same. So, in
this case, the assumption was that the current versions (prior to 6.2.1)
of QNX didn’t support >4G physical address space. That does not make
it a valid assumption that you are guaranteed to never see an address
larger than that. Bottom line is that Armin bad an incorrect assumption,
and he had a bug in his code (thinking that an error response was NULL
when it was not). He based all his programs on an incorrect assumption.
It is not QSS’s fault that he did so, nor is it their responsiblity to
babysit him when he makes mistakes like this. He asked for help, and
once he (reluctantly) provided the information that was requested of
him, his problem was quickly identified. That sounds like GOOD tech
support, not bad, especially considering the abuse he layed down on the
folks trying to help him.

way, it becomes part of OS behavior your customers rely upon, just like all
the proprietary interfaces the OS in question has. Then it becomes a legacy
that you’re bound to support.

Well, again, this is not correct. Sure, it’s perfectly valid to build
code for QNX that uses the QNX proprietary interfaces. There ARE rules,
like the convention of reserving __BLAH as vendor variable names, and
that api functions that start with an underscore are deemed to be more
or less unsupported and subject to change. Relying on a DOCUMENTED
function call, or usage of a function is okay, relying on an assumed
behaviour that isn’t documented is just asking for trouble. …and that
is EXACTLY what Armin did. He set himself up for this to bite him in
the ass, and what do you know… it did.

I disagree. It has nothing to do with lunacy. It has to do with respect to
customers’ codebase and protection of their investments. Of course QNX can’t
anticipate every way to abuse the API, but they can and they should detect
and document all changes in behavior of API functions, no matter if the
change is from bad to good or the other way around.

I don’t think it’s the OS vendor’s responsiblity to try to identify all the
“common” mis-uses of their API.

…and technically the behavior of the function DIDN’T change. It always
returned a value of the mapped object or an error. What changed was the
capabilities of the OS. Previous versions of the OS were not capable of
supporting the >4G address space. New versions are, and as a result any
function that returns an address to memory can now potentially see an
address >4G. The function has not changed, the range of possible return
values has changed, for the entire OS, and I beleive THAT was documented.

In actuality, Armin’s biggest problem was that he asked for help and
was more interested in bitching and berating the folks that helped him.
He was CONVINCED his code was perfect and that ANY suggestion that it
might not be perfect was a personal attack on his person. If his
attitude had been better, and he had provided the requested information
and code snippets sooner, he would have had his answer / solution much
sooner, and this thread wouldn’t be approaching record proportions.
He asked like an ass, and he’s lucky that the folks helping him were
more interesting in helping him despite that.

Cheers,
Camz.

–
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting www.qnxzone.com

63

<camz@passageway.com> wrote in message news:b60t2h$n6d$1@inn.qnx.com…

Igor Kovalenko <> kovalenko@attbi.com> > wrote:
Using mmap() the way Armin did is problematic, but does not conflict
with the logic. Since QNX never before supported address spaces >4Gb,
it was pretty much guaranteed to work.

Igor… come on… that’s just a bad assumption. The best rule of thumb
is that if a certain behaviour is NOT documented that you are taking
a risk in “trusting” that the behaviour will remain the same. So, in
this case, the assumption was that the current versions (prior to 6.2.1)
of QNX didn’t support >4G physical address space. That does not make
it a valid assumption that you are guaranteed to never see an address
larger than that.

You are being idealistic. In real life, especially when you write drivers,
you always end up making some assumptions. Assuming that maximum possible
address space is 4Gb was as good as any other assumption. It was good for
decades.

Bottom line is that Armin bad an incorrect assumption,
and he had a bug in his code (thinking that an error response was NULL
when it was not).

I believe he later corrected himself and pointed that he did not really use
NULL. Pay attention, or you’ll end up making harsh statements based on
assumptions too.

He based all his programs on an incorrect assumption.
It is not QSS’s fault that he did so, nor is it their responsiblity to
babysit him when he makes mistakes like this. He asked for help, and
once he (reluctantly) provided the information that was requested of
him, his problem was quickly identified. That sounds like GOOD tech
support, not bad, especially considering the abuse he layed down on the
folks trying to help him.

I am not talking about quality of support. It is quality of compatibility
testing that bothers me.

way, it becomes part of OS behavior your customers rely upon, just like
all
the proprietary interfaces the OS in question has. Then it becomes a
legacy
that you’re bound to support.

Well, again, this is not correct. Sure, it’s perfectly valid to build
code for QNX that uses the QNX proprietary interfaces. There ARE rules,
like the convention of reserving __BLAH as vendor variable names, and
that api functions that start with an underscore are deemed to be more
or less unsupported and subject to change. Relying on a DOCUMENTED
function call, or usage of a function is okay, relying on an assumed
behaviour that isn’t documented is just asking for trouble. …and that
is EXACTLY what Armin did. He set himself up for this to bite him in
the ass, and what do you know… it did.

You’re being idealistic again. There are just too many aspects of functions’
behavior to document them all. I am sure if you look hard at your own code
you’ll find examples of assumed behavior too. This is not my point and I
don’t know how else I can explain what I am trying to say. People do write
imperfect code and on large scale there’s nothing you can do about it.
However once they made their code work, they consider it ‘good’, even if not
‘perfect’. OS vendors have to deal with this… at least those who want to
stay in business. This is NOT a technical argument, it is a business one. If
you want to argue with this, argue from business perspective.

I disagree. It has nothing to do with lunacy. It has to do with respect
to
customers’ codebase and protection of their investments. Of course QNX
can’t
anticipate every way to abuse the API, but they can and they should
detect
and document all changes in behavior of API functions, no matter if the
change is from bad to good or the other way around.

I don’t think it’s the OS vendor’s responsiblity to try to identify all
the
“common” mis-uses of their API.

Do I have problems with English or you do Camz? Did I say or imply what
you’re objecting to?

…and technically the behavior of the function DIDN’T change. It always
returned a value of the mapped object or an error. What changed was the
capabilities of the OS.

That’s one way to look at it. But opinions are like assholes Camz…

Previous versions of the OS were not capable of
supporting the >4G address space. New versions are, and as a result any
function that returns an address to memory can now potentially see an
address >4G. The function has not changed, the range of possible return
values has changed, for the entire OS, and I beleive THAT was
documented.

Not only range of return values has changed. The return value for a
particular set of parameters has changed. If that does not constitute a
change of behavior for you, we must have incompatible way of thinking.

In actuality, Armin’s biggest problem was that he asked for help and
was more interested in bitching and berating the folks that helped him.
He was CONVINCED his code was perfect and that ANY suggestion that it
might not be perfect was a personal attack on his person. If his
attitude had been better, and he had provided the requested information
and code snippets sooner, he would have had his answer / solution much
sooner, and this thread wouldn’t be approaching record proportions.
He asked like an ass, and he’s lucky that the folks helping him were
more interesting in helping him despite that.

If you want to keep discussing Armin’s personality, please do so in replies
to his postings or start a new thread. I am not talking about his attitude
or who was right or wrong in his discussion with other people. My point is
the lack of sufficient compatibility testing exhibited by QNX over several
past years. There’s a good chance that this discussion would not happen, if
there was such testing in place.

– igor

64

I just wanted to offer a quick comment.

I enjoy reading a spirited debate as much or more than the next guy.
But this thread should be put to rest. As as unbiased observer I
think that both parties were somewhat at fault in the way the problem
was handeled.

But the problem has been solved for a day and a half now and the
argument continues. I’ve been a QNX user for over 15 year now and I
know everyone involved for most of that time. It’s kind of like
watching your parents go through a divorce. It ain’t fun anymore.

So, Mom and Dad, please kiss and make up, for us kids.
Let’s move on, Please!

I know that in the past I’ve been vocal about issues that I’ve had with
QSSL. But I’ve always tried to respect the people at QSSL. I know
that without them I’m SOL. I believe that the QNX OS is the greatest
software in the world. More importantly, I believe tha the people
behind QSSL are te best support team in the world.


As a side note, I have always thought there should be a FAQ on just how
to ask a question and include what kind of evidence of the problem to
try to include in your original post. I’ll try to write down some of
my own ideas and post them later. Other’s can contribute and we can
put together a FAQ.

65

Bill Caroselli wrote:

I enjoy reading a spirited debate as much or more than the next guy.
But this thread should be put to rest.

Especially since it was my thread to begin with, and has nothing to do
with the original question I asked.

Changing the subject header in a reply does not a new thread make.

66

Did you ever figure out what your problem was?

–
Jens

“Mathew Kirsch” <mkirsch@ocdus.jnj.com> wrote in message
news:b629bm$dan$1@inn.qnx.com…

Bill Caroselli wrote:
I enjoy reading a spirited debate as much or more than the next guy.
But this thread should be put to rest.

Especially since it was my thread to begin with, and has nothing to do
with the original question I asked.

Changing the subject header in a reply does not a new thread make.

67

Chris McKillop wrote:
[… ]

This is gonna be my last post in this thread.

good idea, but you have still to show me where I did claim that an
‘entire subsystems of the kernel’ is ‘busted’! I expect an answer
when you are claiming that it’s a statement from me !!!

[…]

You always had a bug in your code Armin,
^^^^

That’s your standard response … but THERE IS NO BUG in our code !

Our mmap() statement is 100% COMPLIANT with the documentation of QNX
6.0, 6.1 and 6.2.0. It has been tested against the existing libraries
of the QNX versions mentioned before … and it was WORKING 100%.

Show me in the documentations of 6.0 to 6.2.0 where are some
restrictions pointed out about the mapped physical address!!

Also, please notice that there is NOTHING PROBLEMATIC WITH OUR mmap()
STATEMENT, even if you and others are repeating it again and again.
What’s problematic is the break in the compatibility between 6.2.0
and 6.2.1 e.g.

Problemetic is also that QSSL seems not to care about the code base of
their customers. It would be a desaster if our PCI based resource
managers would be used in an automotive project with an installed base
of e.g. 200.000 installations and these installations must be upgraded
to 6.2.1!!

What I expect is just a BUG FIX for 6.2.1 in order to solve the
compatibility problem !!

…it just happens that we fixed a bug in OUR code
that exposed yours (which is unfortunate).

http://www.opengroup.org/onlinepubs/007908799/xsh/datatypes.html

off_t is a signed value and mmap() takes an off_t for it’s offset parameter.

that’s nothing new!

FACT is, that your internal back conversion from off64_t to an off_t is
wrong handled regarding the specific parameter constellation of the mmap
call.

Armin

68

camz@passageway.com wrote:

Armin Steinhoff <> a-steinhoff@web.de> > wrote:

It’s hard to be courteous when you hear all the time ‘your code is
wrong’ or insults like ‘do you know how QNX works?’ and on the other

Armin, your code WAS wrong,

regardless how often you like to repeat it, it’s not the case!

Cheers,
Armin

69

camz@passageway.com wrote:

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

However Armin has one point, even while having problematic code. The track
record of QNX on compatibility between even minor versions has been less
than spotless.


I agree that the release notes from QSS are often lacking the level of detail
that I expect, especially in this regard. I don’t think that is the real
issue that you are raising though.


If any change in QNX makes a previously working code (library call)
to fail, for users that’s a failure of the library call.


I would normally agree with you, but in this case you are wrong.
Armin is using a library call incorrectly,

Nonsense … our usage of the mmap() call is compliant to the
documentation of QNX6.0, 6.1 and 6.2.0.
Our mmap() statement is working 100% with QNX6.0, 6.1 and 6.2.0.


the documentation says it will not work with address ranged >4G,

Notice, the documentation mentioned above says nothing about the
address range of the offset parameter. If MAP_PHYS is used, offset
is always a 32bit address and not a signed variable.


and Armin assumed that the MMU would never generate
an address above that on a system with less than that memory.
THAT is not a valid assumption.

So you assume what I have assumed …
what’s the base for these assumptions?
May be you should ask Debbie for creating a new newsgroup
“qdn.public.assuming”? And BTW, what about a “qdn.public.insulting”
for you?


What happened to Armin is simple, he used an library function wrong,

Wrong assumption! See above …


and he
got lucky that on previous versions of QNX6, the library function
was technically “broken” in that it never returned values >4G.
It’s fixed and now it does.

Camz, … the great “fix” from QSSL does now a false back conversion
from off64_t to a off_t. That’s the reason why the behavior is broken!


[ clipped out a lot of nonsens …]

Armin is being stubborn, and foolish. He has so far had it pointed out to
him that he has made TWO mistakes in his code:

  1. assumed that an error result code would be NULL, when in fact it is not.

After reading my code … I have corrected myself.
So your statement is simply wrong …


  1. assumed that result values would remain <4G

Where did I such assumption?? Just curious …


Instead of being polite, and thanking the individuals that tried to help
him (despite his rude and stubborn behaviour and refusal to admit he made
a coding error), he has only berated those that tried to help him…
That is just stupid, rude, etc.

Sorry, it’s also rude to claim that problems are always problems in the
code of QNX customers … even when it is evident that a problem is
related to a new library version.

So lets be blunt: Armin stop being a dick.

I know that you feel like being a part of QNX… so everyone criticizing
QNX is hurting you.

Consequentely all “unthankful” individuals will be attacked and insulted
by you and denunicated ‘not to know how QNX works’.

Your behaviour is known since years… and if you think I’m assuming
something wrong, just read the legendary SMP thead again…

http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&threadm=5ak0ol%24goh%40lana.zippo.com&rnum=1&prev=/groups%3Fq%3DSMP%2Bcamz%2Bigor%2Barmin%26btnG%3DGoogle-Suche%26hl%3Dde%26lr%3D%26ie%3DISO-8859-1

Cheers,
Armin

70

camz@passageway.com wrote:

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

Actually it is a very bad analogy. Unprotected access to shared
memory is plain wrong because it is against the common logic.

[ clip …]
In actuality, Armin’s biggest problem was that he asked for help and
was more interested in bitching and berating the folks that helped him.

‘Helped him’?? That’s just your theory …

He was CONVINCED his code was perfect

Our code IS correct … at least for 6.0, 6.1 and 6.2.0.

and that ANY suggestion that it
might not be perfect was a personal attack on his person.

That would only be possible if I would feel and act like you.
QNX is for me just a tool and nothing else …

BTW, this is a technical news group, so you should look for
an other forum for personal insults…

Armin

71

Mathew Kirsch wrote:

Bill Caroselli wrote:
I enjoy reading a spirited debate as much or more than the next guy.
But this thread should be put to rest.

Especially since it was my thread to begin with, and has nothing to do
with the original question I asked.

Changing the subject header in a reply does not a new thread make.

Mathew, when reading the thread I had just discovered a libc
incompatibility and pointed it out. I had expected to get a short answer
about what QSSL has changed.

That “battlefied” was not foreseeable …

Armin

72

“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:3E84DE60.E3B8F791@web.de…

camz@passageway.com > wrote:

Your behaviour is known since years… and if you think I’m assuming

Ain’t that true for all of us Armin…

something wrong, just read the legendary SMP thead again…


http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&threadm=5ak0ol%24goh%40lan

a.zippo.com&rnum=1&prev=/groups%3Fq%3DSMP%2Bcamz%2Bigor%2Barmin%26btnG%3DGoo
gle-Suche%26hl%3Dde%26lr%3D%26ie%3DISO-8859-1

Hehehe :wink:

Andrew Boyd kept his cool, which is not hard in Kanata…
Armin was already one of the few QNX users who did not ever agree with QNX
on anything…
Camz was already the one who always did, even though Stephen did not yet
think so…
Colin was still watching out for those flesh-eating parrots in the
Kiwiland…
Michael & Rennie were still freezing their butts in the North Silicon
Valley…
Mitchell was making bogus arguments… where is he now to read them?
My english was poor…
My arguments had more roughness than refinement…
And I was … younger :wink:

The real jewel though was what Armin called poor Linux folks back then (even
though it was a typo), but it went totally unnoticed. Curious minds are
challenged to find the quote :wink:

Those were the days my friend, those were the days…
Happy fools day, everyone!

– igor

73

Mario Charest wrote:

Sorry coudn’t resists > :wink:> )))))

I’m reading this thread late (not upset I missed it
“live” :wink:; but this is definately the best post in
the thread :slight_smile:

Rennie

74

Mitchell was making bogus arguments… where is he now to read them?

He is now a teacher.

75

“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:b649nj$ms7$1@inn.qnx.com…

Jens H Jorgensen wrote:
Did you ever figure out what your problem was?

The problem is a break in the compatibility between
previous releases and 6.2.1.

It is not possible with 6.2.1 to map PCI device memory using mmap()!

Our mmap() code line is compliant with the documentations and release
notes of 6.0, 6.1, 6.2.0.

Armin

Not your problem Armin! - but Mathew’s original problem with sudden
lock-up’s on his QNX server?

–
Jens

76

Igor Kovalenko <kovalenko@attbi.com> wrote:

“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:> 3E84DE60.E3B8F791@web.de> …
camz@passageway.com > wrote:

Your behaviour is known since years… and if you think I’m assuming

Ain’t that true for all of us Armin…

something wrong, just read the legendary SMP thead again…


http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&threadm=5ak0ol%24goh%40lan
a.zippo.com&rnum=1&prev=/groups%3Fq%3DSMP%2Bcamz%2Bigor%2Barmin%26btnG%3DGoo
gle-Suche%26hl%3Dde%26lr%3D%26ie%3DISO-8859-1


Hehehe > :wink:

Andrew Boyd kept his cool, which is not hard in Kanata…

And kept us amused with stories of hell freezing over…

Colin was still watching out for those flesh-eating parrots in the
Kiwiland…

Flesh eating parrots?!! I guess that’s better than a sheep joke… ;v)

–
cburgess@qnx.com

77

Armin Steinhoff <a-steinhoff@web.de> wrote:

camz@passageway.com > wrote:
Igor Kovalenko <> kovalenko@attbi.com> > wrote:

However Armin has one point, even while having problematic code. The track
record of QNX on compatibility between even minor versions has been less
than spotless.


I agree that the release notes from QSS are often lacking the level of detail
that I expect, especially in this regard. I don’t think that is the real
issue that you are raising though.


If any change in QNX makes a previously working code (library call)
to fail, for users that’s a failure of the library call.


I would normally agree with you, but in this case you are wrong.
Armin is using a library call incorrectly,

Nonsense … our usage of the mmap() call is compliant to the
documentation of QNX6.0, 6.1 and 6.2.0.
Our mmap() statement is working 100% with QNX6.0, 6.1 and 6.2.0.

the documentation says it will not work with address ranged >4G,

Actually, the >4G is completely irrelevant here, and a red herring.

Notice, the documentation mentioned above says nothing about the
address range of the offset parameter. If MAP_PHYS is used, offset
is always a 32bit address and not a signed variable.

I looked at the documentation for 6.2.0. It says that the final
parameter for mmap is an off_t off. It then takes a bit of header digging,
off_t is __OFF_T, which is either a signed 32 or 64 bit integer, a bit more
work finds out it is a signed 32 bit integer. (That it is a 32 bit
value is also strongly hinted at by mmap64() for “large file support”.)

Passing in an unsigned value > 2G as a signed 32-bit integer and then
expecting particular behaviour from this is not good programming.

MAP_PHYS is NOT documented as stating that it will treat the signed value
as unsigned. And, the 6.2.0 docs from MAP_PHYS under mmap() actually say,
“You should use mmap_device_memory() instead of MAP_PHYS.”

In pre-6.2.1 versions, QNX quietly allowed this out-of-range value to
be passed to the function and quietly did the “expected” thing. This
behaviour was changed in 6.2.1, and, unfortunately, broke some existing
code.

Since we changed this behaviour, we should have release noted it. (And,
as Steve Reed posted, I think this will be (have been?) added to the
release notes.)

-David

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

78

David Gibbs wrote:

Armin Steinhoff <> a-steinhoff@web.de> > wrote:

[]
In pre-6.2.1 versions, QNX quietly allowed this out-of-range value to
be passed to the function and quietly did the “expected” thing. This
behaviour was changed in 6.2.1, and, unfortunately, broke some existing
code.

Since we changed this behaviour, we should have release noted it.

Such a release note doesn’t help much … it would be better to announce
such a change in advance in order to make sure that we all can react in
advance.

Armin

(And,
as Steve Reed posted, I think this will be (have been?) added to the
release notes.)

-David

79

“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:b6a11u$8hj$1@inn.qnx.com…

David Gibbs wrote:
Armin Steinhoff <> a-steinhoff@web.de> > wrote:

[]
In pre-6.2.1 versions, QNX quietly allowed this out-of-range value to
be passed to the function and quietly did the “expected” thing. This
behaviour was changed in 6.2.1, and, unfortunately, broke some existing
code.

Since we changed this behaviour, we should have release noted it.

Such a release note doesn’t help much … it would be better to announce
such a change in advance in order to make sure that we all can react in
advance.

That would be one of major purposes of beta programs. Assuming of course
that betas have proper release notes. Which they don’t, unfortunately.

– igor

80

Igor Kovalenko <kovalenko@attbi.com> wrote:

That would be one of major purposes of beta programs. Assuming of course
that betas have proper release notes. Which they don’t, unfortunately.

Now, THAT is something I can agree with you on. It’s been a major peeve of mine
that the betas don’t have any release notes, and we have to guess which things to
test and we’re lucky if we notice the new things they slipped in.

Cheers,
Camz.

\

Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting www.qnxzone.com