chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Compiling Chicken with Watcom .. type errors


From: Bob McIsaac
Subject: Re: [Chicken-users] Compiling Chicken with Watcom .. type errors
Date: Mon, 23 Jan 2006 23:07:18 -0500
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050716)

Sergey Khorev wrote:
Finally I've figured out the main showstopper to get Chicken compiled by Watcom (at least at the moment). To be precise, chicken.exe and chicken-static.exe can be compiled but they don't work :)

The problem is in the default Watcom calling convention (it's similar to MSVC's __fastcall): it uses registers to pass few first arguments. This doesn't work for functions with a variable number of arguments.
E.g., the following program will not work properly without the -ecc switch (== use __cdecl calling convention)
-----
#include <stdio.h>

typedef void (*proc3)(int a1, int a2, int a3);

void proc(int a1, int a2, int a3, ...)
{
	printf("%d %d %d\n", a1, a2, a3);
}

int main()
{
	proc3 p = (proc3)proc;
	p(1, 2, 3);
	return 1;
}
-----
But, the -ecc switch causes internal compiler error.
I've created a bug report (http://bugzilla.openwatcom.org/show_bug.cgi?id=505) for it. Workaround "#pragma inline-depth(0);" doesn't help.

If I correctly undertsand, Chicken-generated C can cast to C_procXX both "normal" and vararg functions. Should we wait for feedback or does anyone know any workarounds?

Felix, can we add __cdecl for each C_procXX typedef and every function, which can be called by casting to C_procXX? Theoretically speaking, this might help to avoid internal compiler error because not all functions will be __cdecl'ed, but I hardly believe in that.

PS Please keep both my emails in cc field, it's intended.


_______________________________________________
Chicken-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/chicken-users



  
Hi:

I moved my computer away from the internet, fired up ol win98 and tried
your program.  As expected, it compiled ok and printed garbage.

Next I removed the cast from the function pointer
      proc3 p = (proc3)proc;  // (proc3) cast hides error


Now the problem is exposed:-

cd C:\bins\wtest
wmake -f C:\bins\wtest\v1.mk -h -e
wcc386 var.c -i=C:\watcom\h;C:\watcom\h\nt -w4 -e25 -zq -od -d2 -6r -bt=nt -mf
var.c(14): Warning! W102: Type mismatch (warning)
var.c(14): Note! N2003: source conversion type is 'void (*)(int __p1,int __p2,int __p3,... )'
var.c(14): Note! N2004: target conversion type is 'void (*)(int __p1,int __p2,int __p3)'
wlink name v1 d all SYS nt op m op maxe=25 op q op symf @v1.lk1
Execution complete


The solution is the to have the function pointer typedef match the
declaration of the pointed to function which has ellipses.
  
typedef void (*proc3)(int a1, int a2, int a3, ...); // added 'dots' to match function

Depending upon design of the source, it might be better to include
<stdarg.h>  which has _va_list and so on. Note that watcom provides
examples of a function that iterates through variable parameters. It is
at least instructive if not useful here.

Hope this helps,
-BobMc-


reply via email to

[Prev in Thread] Current Thread [Next in Thread]