Subject: | |
From: | |
Reply To: | |
Date: | Wed, 14 Jul 2010 09:55:52 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
So DBGET would not return a 50 if there is enough space on the stack, so
it is still possible to over-run the buffer and corrupt other data items
in your stack.
It is better to compare the length item of the status parm with the
sizeof the databuffer.
On a positive note: The fact that DBGET returns a 50 when there is not
enough space on the stack is a great example of why the HP3000 is so
reliable. In other environments the process would just stop, coredump,
or just simply go away without a clue. Then it could take hours, maybe
days to find the problem code. This shows the design of MPE was to keep
working where other platforms crash and burn!
Mike.
Keven Miller wrote:
> ----- Original Message ----- From: Denys Beauchemin
> This is what is in the IMAGE reference manual for DBGET error 50:
>
> "Buffer is too small (will only be returned if buffer is
> too small and the data transfer would write over
> stack markers in the user's stack)."
>
> In appendix A it says:
> "Calling program's buffer (identified by buffer parameter)
> is too small to accommodate the amount of information
> that DBGET or DBINFO wishes to return without extending
> into the parameters area. This message is returned only if
> the buffer is the last item in the user's stack, and will
> overflow the stack boundaries."
>
>
> [Keven]
> What this means to me is that in the CISC world,
> the data transfer would go above the top-of-stack in the user stack.
> (ie beyond the S register).
>
> In the RISC world, I would assume a similar response.
>
> Keven Miller
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
|
|