[Coco] os9 intercept call from C

[Walter Zambotti]

Ok so summing up!

My original issue appeared to be a missing intercept function from the
standard clib.

Which I tried to workaround by writing my own, that didn't work to well
at all.

However this was not the case and it was the use of the C Ansi Front end
(from the
Climax C compiler) that was rehashing names longer than 8 characters to
hashes
resulting in the link failures.

The work around to this Ansi Front end feature is to truncate names
longer than
8 characters to 8.  Which is what the normal C compiler does anyway.

Looking in the standard clib there are quite a few functions that are
longer than
8 chars so this would impact quite a bit.

The other work around is of course not to use the Ansi Front end but if
as I am
porting a large ansi C application from another platform the refactoring
would become
problematic.

So thanks guys for all the help.

Good to see there a still CoCo coders out there!

Walter

On 2020-04-19 10:35, Walter Zambotti wrote:
> On 2020-04-19 01:03, Gene Heskett wrote:
>> On Saturday 18 April 2020 12:44:08 Walter Zambotti wrote:
>>
>>> Opps nine characters long!!!
>>>
>>> Which is exactly when the Ansi front end will start converting long
>>> variable names to hashes.
>> What ansi front end are you refering to?
> The Ansi front end that comes with the Climax C compiler.
> I'm using the -A switch on cc to trigger ansi mode.
>
>>> On 2020-04-19 00:41, Walter Zambotti wrote:
>>>> That's what I have trying to say guys.
>>>>
>>>> The intercept function is not in the standard library as expected.
>>>>
>>>> At least for me if I comment out my intercept function then it fails
>>>> to link with unresolved reference to intercept.
>>>>
>>>> Figured out what is going wrong with the missing intercept library
>>>> function.
>>>>
>>>> An rdump shows it is in the library.
>>>>
>>>> The problem starts when compiling with Ansi front end.  It converts
>>>> the reference to _hexvalue which I can see on the _ntbl file.
>>>>
>>>> Which it should not do.  Especially since 'intercept' is only 8
>>>> characters long.
>>>>
>>>> I suppose that's another bug in the Ansi front end.
>>>>
>>>> I reverted the code back to K&R and it compiles and links with no
>>>> problem.
>>>>
>>>> Thanks guys
>>>>
>>>> Walter
>>>>
>>>> On 2020-04-18 23:38, Alex Evans wrote:
>>>>> Largely ignoring the fact that the above code uses ANSI syntax and
>>>>> the only MW C Compiler I am aware of for the CoCo uses K&R. If you
>>>>> use the provided intercept function in the library, the function to
>>>>> be called is a normal C function which takes an integer as a
>>>>> parameter (no RTI). If you are going to finable about directly
>>>>> using F$Icpt to set you trap, it needs to return using RTI. In
>>>>> addition, you need to set the pointer to the routine's storage area
>>>>> in U, but in the case of the function you have provided, it does
>>>>> not appear to need any storage space, so the fact you didn't set U
>>>>> shouldn't be a problem.
>>>>>
>>>>> I would think (untested) the answer would be:
>>>>> int catchall();
>>>>>
>>>>> int intflag=0;
>>>>>
>>>>> main(argc, argv)
>>>>> int argc;
>>>>> char *argv[];
>>>>> {
>>>>>   intercept(catchall);
>>>>>   while (!intrlag) {
>>>>>     pause();
>>>>>     write(1, "*", 1);
>>>>>   }
>>>>> }
>>>>>
>>>>> catchall(sig)
>>>>> int sig;
>>>>> {
>>>>>   intfrag=sig==0x03;
>>>>> }
>>>>>
>>>>> If your really, really want to directly use the system call, you
>>>>> need to also pull the signal number from somewhere. The routine
>>>>> expexted by F$cpt is a machine code routine, and sig will probably
>>>>> not be passed on the stack in the manner that MW C expects, so you
>>>>> need to figure out where it would be.
>> Cheers, Gene Heskett