I think I asked this question on this forum some time ago but with a different solution format.
However I can see that it would cause problems potentially with the c language type system pehaps.

So I was thinking of a new possible syntax and my question, if you can help me, is would this likely cause any c language process conflcts?
I used to use SAS C up to 6.5. I've used Storm C as well.

I'm looking to write my own c compiler for a project that I am working on.
So I'm looking for a way to return mutliple results directly from functions.

The usual workaround for the above would be something like:
GetMouse(&x,&y)

But for my project it will be better if I can do these directly.
It looks to me square brackets don't seem to serve any purpose before a function assingment.
So in your opinion would the syntax I'm suggesting be free of conflicts with any current processes?

As in the title the format I'm looking to implement is:
[int x,int y] = GetMouse();
Where both x and y are returned directly by the function GetMouse.

I know that c normally only returns a single register (like d0).
But, my code will be doing things differently than that.
So that wouldn't be an issue.

Does anyone know of any other potential conflicts with any existing c processes?
That could include C++ and any other variants if you know them.

@gonegahgah

Returning multiple results at once is a feature of some languages, e.g. Go.

You'd be outside the regular ABI with this approach in C. What you might be able to do is to devise some syntactical sugar that transforms your expression into something that translates to argument passing by reference, while keeping the original functions unchanged. In which case,

[ int x, int y ] = GetMouse();

would be translated into

int x, y; GetMouse(&x, &y);

This obviously requires enforcing where the by reference modified parameters go in relation to any named ones. First, would make sense. It also leaves the question of how any actual return is handled. You might decide that functions with multiple returns by reference don't have a vanilla return and are always void. That would be simplest.

_________________
Doing stupid things for fun...

Alternatively, just return a structure. You get some copy overhead returning by value but many c++ compilers have strategies for allocating by value objects in the calling stack frame, meaning that there's no real copy involved.

Last edited by Karlos on 19-Mar-2024 at 04:05 PM.

_________________
Doing stupid things for fun...

@Karlos

Thank you for those suggestions.

I was thinking that the big problem might be that function results could be used directly.
And that my syntax might make that difficult.
But I can't find any c examples of that?

int max(int a, int b) {
if (b > a) {
a = b;
}
return a;
}

int main() {
int value = max(1,max(3,5)); // Is this not supported?
printf("Maximum result is %d\n",value);
return 0;
}

Was my memory of this faulty?
Do you know of any languages that you can put function results directly as arguments?

Just thought to test it... That compiles fine (though I had to fix forgotten syntax).
Ah, that is an interesting conundrum. I will have to pause and think about it...

Last edited by gonegahgah on 31-Mar-2024 at 12:38 PM.

@gonegahgah

Any expression that results in a value, including a function call, can be used as a function argument in a call. So you can totally do func(func(func(.... as much as you need, provided func returns a value type compatible with it's own input parameter(s)*

*Original QuakeC was a notable exception to this due to the way parameters are marshalled.

Where you can run into problems with this is when an expression results in a reference to a value rather than the value itself.

A case in point, I have a software synth project that uses C++ std::shared_ptr to manage discrete packets of audio. My implementation provides a custom deleter for these that recycles a number of packets for improved throughput by bypassing interaction with the memory allocator.

Some lower level functions rely on vanilla pointers. I had a call that distilled to something like this:

takes_vanilla_pointer(returns_shared_ptr().get());

This was a mistake. The scope of the shared pointer returned by the call to returns_shared_ptr ends after I call .get() on it. Which then deletes it. I'm left with a vanilla pointer to memory I just released being passed to the takes_vanilla_pointer(). To borrow a quote from Brass Eye, "It was the last thing they wanted to happen."

The solution to this was to explicitly not abbreviate the code this way. I had to assign the result of the function returning the shared pointer to a value first, then call the lower level function with that value. I didn't really have to invoke get() in either case, but it was for explicitness sake. This second version ensures the shared packet pointer is in scope while the second function executes and all was well.

_________________
Doing stupid things for fun...