From Newsgroup: comp.os.vms

Anybody got a description of cma$tis_errno_get_addr?

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/15/2025 9:20 PM, Arne Vajh|+j wrote:

Anybody got a description of cma$tis_errno_get_addr?

Arne

Returns the address of the thread's errno
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/15/2025 9:49 PM, John Reagan wrote:

On 9/15/2025 9:20 PM, Arne Vajh|+j wrote:

Anybody got a description of cma$tis_errno_get_addr?

Returns the address of the thread's errno

That was what I expected.

But I am having problems.

It actually works in C.

But when I call it in Pascal, then I get the correct
address but the value at the address is not correct.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/15/2025 10:15 PM, Arne Vajh|+j wrote:

On 9/15/2025 9:49 PM, John Reagan wrote:

On 9/15/2025 9:20 PM, Arne Vajh|+j wrote:

Anybody got a description of cma$tis_errno_get_addr?

Returns the address of the thread's errno

That was what I expected.

But I am having problems.

It actually works in C.

But when I call it in Pascal, then I get the correct
address but the value at the address is not correct.

Calling decc$crtl_init does not solve the problem.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms


On 9/15/25 9:16 PM, Arne Vajh|+j wrote:

On 9/15/2025 10:15 PM, Arne Vajh|+j wrote:

On 9/15/2025 9:49 PM, John Reagan wrote:

On 9/15/2025 9:20 PM, Arne Vajh|+j wrote:

Anybody got a description of cma$tis_errno_get_addr?

Returns the address of the thread's errno

That was what I expected.

But I am having problems.

It actually works in C.

But when I call it in Pascal, then I get the correct
address but the value at the address is not correct.

Calling decc$crtl_init does not solve the problem.

Never tried it from Pascal. Since errno is a CRTL thing, it's not clear
to me that it makes any sense to do so, but if you're trying to debug a
library called from the Pascal code, maybe. In any case the following
are the notes I made for myself a long time ago:

Get errno from VMS debugger:

set image CMA$TIS_SHR
set radix hexadecimal
call CMA$TIS_ERRNO_GET_ADDR
!
! The above returns an address
!
examine/long/decimal <cut'n paste the address>
!
! The above returns errno content.
! If errno content is 65535 (EVMSERR == 65535)
! continue your debugging session with right below
!
call CMA$TIS_VMSERRNO_GET_ADDR
!
! The above returns an address
!
examine/condition <cut'n paste the returned address>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/15/2025 10:39 PM, Craig A. Berry wrote:

On 9/15/25 9:16 PM, Arne Vajh|+j wrote:

On 9/15/2025 10:15 PM, Arne Vajh|+j wrote:

On 9/15/2025 9:49 PM, John Reagan wrote:

On 9/15/2025 9:20 PM, Arne Vajh|+j wrote:

Anybody got a description of cma$tis_errno_get_addr?

Returns the address of the thread's errno

That was what I expected.

But I am having problems.

It actually works in C.

But when I call it in Pascal, then I get the correct
address but the value at the address is not correct.

Calling decc$crtl_init does not solve the problem.

Never tried it from Pascal.-a Since errno is a CRTL thing, it's not clear
to me that it makes any sense to do so, but if you're trying to debug a library called from the Pascal code, maybe.

Pascal calling C++ library.

-a In any case the following
are the notes I made for myself a long time ago:

Get errno from VMS debugger:

set image CMA$TIS_SHR
set radix hexadecimal
call CMA$TIS_ERRNO_GET_ADDR
!
! The above returns an address
!
examine/long/decimal <cut'n paste the address>
!
! The above returns errno content.
! If errno content is 65535 (EVMSERR == 65535)
! continue your debugging session with right below
!
call CMA$TIS_VMSERRNO_GET_ADDR
!
! The above returns an address
!
examine/condition <cut'n paste the returned address>

Interesting.

The value I see is indeed 65535.

One question answered, but two new questions pop up.

1) How does the C++ library know that the main program
is Pascal and not C (for C I get a normal errno value)?

2) The address returned by CMA$TIS_VMSERRNO_GET_ADDR
point to another mysterious value not matching anything.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms


On 9/15/25 9:56 PM, Arne Vajh|+j wrote:

On 9/15/2025 10:39 PM, Craig A. Berry wrote:

call CMA$TIS_VMSERRNO_GET_ADDR
!
! The above returns an address
!
examine/condition <cut'n paste the returned address>

Interesting.

The value I see is indeed 65535.

One question answered, but two new questions pop up.

1) How does the C++ library know that the main program
-a-a is Pascal and not C (for C I get a normal errno value)?

2) The address returned by CMA$TIS_VMSERRNO_GET_ADDR
-a-a point to another mysterious value not matching anything.

On #2, if there are any likely-looking message files, it's possible that
SET MESSAGE with the right one might get the condition value
translatable to a meaningful message.

On #1, remember that the value of errno doesn't mean anything except immediately after the error, so if C is successful but Pascal is not,
the fact that you get different errno values doesn't really tell you
anything. If there is an error from both languages, then it does sound
like something is different about the initialization of the image or the debugger session. Since the debugger does have language-specific
features, it may be a more likely suspect.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/16/2025 7:31 AM, Craig A. Berry wrote:

On 9/15/25 9:56 PM, Arne Vajh|+j wrote:

On 9/15/2025 10:39 PM, Craig A. Berry wrote:

call CMA$TIS_VMSERRNO_GET_ADDR
!
! The above returns an address
!
examine/condition <cut'n paste the returned address>

Interesting.

The value I see is indeed 65535.

One question answered, but two new questions pop up.

1) How does the C++ library know that the main program
-a-a-a is Pascal and not C (for C I get a normal errno value)?

On #1, remember that the value of errno doesn't mean anything except immediately after the error, so if C is successful but Pascal is not,
the fact that you get different errno values doesn't really tell you anything.-a If there is an error from both languages, then it does sound
like something is different about the initialization of the image or the debugger session.-a Since the debugger does have language-specific
features, it may be a more likely suspect.

It is a about this.

Trying a gazillion things has let me to conclude that
C free sets errno when called on something allocated
with Pascal malloc_c_str.

Not yet clear to me why it does that. But I will find
a way to workaround it.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/17/2025 9:13 PM, Arne Vajh|+j wrote:

On 9/16/2025 7:31 AM, Craig A. Berry wrote:

On 9/15/25 9:56 PM, Arne Vajh|+j wrote:

On 9/15/2025 10:39 PM, Craig A. Berry wrote:

call CMA$TIS_VMSERRNO_GET_ADDR
!
! The above returns an address
!
examine/condition <cut'n paste the returned address>

Interesting.

The value I see is indeed 65535.

One question answered, but two new questions pop up.

1) How does the C++ library know that the main program
-a-a-a is Pascal and not C (for C I get a normal errno value)?

On #1, remember that the value of errno doesn't mean anything except
immediately after the error, so if C is successful but Pascal is not,
the fact that you get different errno values doesn't really tell you
anything.-a If there is an error from both languages, then it does sound
like something is different about the initialization of the image or the
debugger session.-a Since the debugger does have language-specific
features, it may be a more likely suspect.

It is a about this.

Trying a gazillion things has let me to conclude that
C free sets errno when called on something allocated
with Pascal malloc_c_str.

Not yet clear to me why it does that. But I will find
a way to workaround it.

And in case mr. Reagan wants to take a look:

Documentation state:

<quote>
The memory allocated with MALLOC_C_STR must be deallocated with
the C free() routine.
</quote>

But:

$ type re.pas
program re(input,output);

[external('decc$free')]
procedure free_c_str(ptr : c_str_t); external;

type
integer_ptr = ^integer;

[external]
function cma$tis_errno_get_addr : integer_ptr; external;

[external]
function cma$tis_vmserrno_get_addr : integer_ptr; external;

var
p : c_str_t;

begin
p := malloc_c_str('xxx');
writeln(cma$tis_errno_get_addr^, cma$tis_vmserrno_get_addr^);
free_c_str(p);
writeln(cma$tis_errno_get_addr^, cma$tis_vmserrno_get_addr^);
end.
$ pas re
$ link re
$ run re
0 0
65535 1409636
$ type re.c
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>

int main()
{
char *p = malloc(4);
printf("%d\n", errno);
free(p);
printf("%d\n", errno);
return 0;
}

$ cc re
$ link re
$ run re
0
0

Arne



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/17/2025 9:26 PM, Arne Vajh|+j wrote:

On 9/17/2025 9:13 PM, Arne Vajh|+j wrote:

On 9/16/2025 7:31 AM, Craig A. Berry wrote:

On 9/15/25 9:56 PM, Arne Vajh|+j wrote:

On 9/15/2025 10:39 PM, Craig A. Berry wrote:

call CMA$TIS_VMSERRNO_GET_ADDR
!
! The above returns an address
!
examine/condition <cut'n paste the returned address>

Interesting.

The value I see is indeed 65535.

One question answered, but two new questions pop up.

1) How does the C++ library know that the main program
-a-a-a is Pascal and not C (for C I get a normal errno value)?

On #1, remember that the value of errno doesn't mean anything except
immediately after the error, so if C is successful but Pascal is not,
the fact that you get different errno values doesn't really tell you
anything.-a If there is an error from both languages, then it does sound >>> like something is different about the initialization of the image or the >>> debugger session.-a Since the debugger does have language-specific
features, it may be a more likely suspect.

It is a about this.

Trying a gazillion things has let me to conclude that
C free sets errno when called on something allocated
with Pascal malloc_c_str.

Not yet clear to me why it does that. But I will find
a way to workaround it.

And in case mr. Reagan wants to take a look:

Documentation state:

<quote>
The memory allocated with MALLOC_C_STR must be deallocated with
the C free() routine.
</quote>

But:

$ type re.pas
program re(input,output);

[external('decc$free')]
procedure free_c_str(ptr : c_str_t); external;

And nothing to look at except my buggy code.

That declaration should be:

[external('decc$free')]
procedure free_c_str(%IMMED ptr : c_str_t); external;

That is why free was reporting an error.

Arne


--- Synchronet 3.21a-Linux NewsLink 1.2