[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pcc-list
Subject:    [Pcc] More issues with stdcall
From:       Antoine Leca <antoine64leca () hotmail ! com>
Date:       2015-01-26 12:31:39
Message-ID: BLU436-SMTP1151F8EE9810EB3C1DE0D37B0350 () phx ! gbl
[Download RAW message or body]

Hi,

I found a new bad surprise with stdcall: those attributes seem to behave
like a qualifier much more than a storage class.

For example, if one writes

	int __stdcall f(void),
	    __stdcall g(void);

then both functions are declared as using the stdcall convention.
Currently PCC does not grok that.
(Obviously, all of this stuff also applies to the recent added fastcall
attribute, or to the "no-effect" cdecl attribute.)

Also, when one needs to shuffle function pointers, for example as
parameters, one writes

	void h(int, int(__stdcall*)(int), int(__stdcall*o)());

Note that the "__stdcall" should be inside the (), along the *
PCC currently chokes on this. One can rewrite it as

	typedef int (__stdcall * pf)();
	typedef int (__stdcall * pf1)(int);
	void h(int, pf1, pf o);

but this is just showing another bug, which is that the __stdcall
attribute is not attached to the type (here, the typedef.)


I know stdcall is pretty much broken in several ways, but it seems to me
that this issue requires thinking about enlarging the grammar, and I am
not quite sure which is the way to go...


Antoine
_______________________________________________
Pcc mailing list
Pcc@lists.ludd.ltu.se
https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc
[prev in list] [next in list] [prev in thread] [next in thread]