World: r3wp

You should compile it in verbose mode (-v 6) and check the callbacks 
calling convention in the symbols block at the end of the compilation 
logs.

It should be stdcall or cdecl. If you see ??, it means the compiler 
hasn't been able to solve it.

Bingo, it says ?? for the audio callback

Ah!

The ?? is the default value for cconv. When the compiler encounters 
a get-word!, it propagates the cconv from the function using it as 
argument.

How are you passing callbacks? Same way as with GTK binding through 
a variadic function?

As I noted above, no variadic functions in the other bindings yet

Can you show me the code pattern you're using for the callbacks in 
SDL audio binding?

stream!: alias struct! [
;	data				[binary!]
	index				[binary!]
	rest				[integer!]
]
fetch-audio: function [  ; Read sound buffer to be played.
	[callback]
	source				[stream!]
	sink				[binary!]
	size				[integer!]
	/local slice
][
	slice: source/rest
	if slice > size [slice: size]

;	copy-part source/index sink slice
	sdl-mix-audio sink source/index slice sdl-mix-max-volume

	source/index: source/index + slice
	source/rest: source/rest - slice
]

Ok, so how are you installing the fetch-audio callback?

desired/callback: as-integer :fetch-audio

desired:	declare sdl-audio-spec!

Ok, so the cause is obvious, no way for the compiler to figure out 
the cconv in such case.

I think that I will just accept both 'stdcall and 'cdecl attribute 
in cases like this where the compiler can't determine the right calling 
convention. I will also add a check at the end of the compilation 
to raise errors for unresolved calling conventions.

That's nice, but why not default to cdecl?

The default needs to be a non-usable value for the compiler to be 
able to catch unresolved calling convention. If it's cdecl or stdcall, 
the compiler won't report the error which can lead to stack corruption 
at runtime.

Are you sure the current resolver is watertight, then?

The current resolver only works for simple cases, basically, only 
when you're directly passing a function pointer as argument to a 
function.

I need to add the unresolved calling convention error routine.

When such error will be reported, users would need to provide manually 
this information, by adding 'cdecl or 'stdcall as attribute.

I don't really see a connection between the function a pointer is 
passed to and the function that will eventually call it

Well, it depends if the function taking a function pointer is invoking 
it directly or if it's passing it to another function (local or imported). 
In the former case, the compiler can set the right cconv itself, 
in the latter case, it can't and need some help from the user.

Yes, so is the current inferer always guessing right?

Let me have a look at the specs, I remember there was an edge case 
documented there...

No trace of any special cases in the specs anymore. So, the compiler 
is always guessing right, when it can guess. When it can't, it leaves 
the cconv in undetermined state (??).

The inferer is very simple, it just looks at the cconv of the calling 
function and propagates it to the callback. If the callback has already 
a cconv defined, it checks if both cconv matches, and raise an error 
if it's not the case.

Not much to report yet, except this:

bash-4.0# hello-SQLite-world                                     
                                                                 
           
SQLite version: 3.6.22
SQLite version number: 3006022

SQLite source ID: 2010-01-05 15:30:36 28d0d7710761114a44a1a3a425a6883c661f06e7

Good start!

Ok, these are the changes I will make today wrt cconv resolution:

- 'cdecl and 'stdcall keywords will be accepted as function attributes.

- 'callback attribute remains, it lets the compiler decide on the 
cconv to apply. If it fails to solve it, an error will be raised 
and user will have to manually set it instead (replacing 'callback 
by 'cdecl or 'stdcall).

You can only have one function attribute?

then we need typesets and attribute sets :-)

BrianH: no, there are several others that can be mixed together, 
but only one from [callback stdcall cdecl].

So that means that any function declared as 'cdecl or 'stdcall can 
now be used as a callback? Or can all functions?

Only those having one of those above 3 attributes can be used as 
"callbacks".

I think I see your concern. It might be probably less confusing to 
leave the 'callback keyword mandatory for "callbacks" and accept 
'stdcall and 'cdecl as additional attributes, but it is a bit more 
verbose also.

What's the difference between a cdecl callback and a regular cdecl 
function?

IIRC, no differences, the callback attribute was just meant to help 
the compiler figure out that the cconv has to be solved at compile-time.

I thought so, so why not drop the callback attribute and let the 
programmer decide whether it is used as a callback or not?

Yes, it would be the logical thing to do.

But in such case, users woud have to always set the cconv manually 
and the compiler wouldn't be able to help catch errors.

The current 'callback attribute triggers the compiler inferer and 
cconv errors.

No, I mean your original plan was alright

Well, having just "cdecl" or "stdcall" might not hint enough the 
reader that the function is used as a callback...

But that's the point: it may not be

Just wondering: Why do functions need to be marked as being able 
to be callbacks? Is it to prevent them from being inlined?

Answered that a few lines above: "the callback attribute was just 
meant to help the compiler figure out that the cconv has to be solved 
at compile-time."

It is only related to calling convention resolution.

If we get rid of 'callback attribute, then only 'cdecl attribute 
will be required and it will have to be set manually everywhere it 
is needed.

The stdcall wouldn't be required as it is the internal calling convention 
used by native Red/System functions.