From: arne@vajhoej.dk
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
>>>>
>>>> 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)?
>>
>>> 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.
>>
>> 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:
>
>
> The memory allocated with MALLOC_C_STR must be deallocated with
> the C free() routine.
>
>
> 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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
