Hacker News Reader

Comment by miohtama | Hacker News Reader

The whole C interface is clunky because C does not support multiple return values. More advanced languages should not be forced to deal with it.

View on HN

You can return structs from C functions (note, I don't mean pointers, I mean whole structs). You can pass in structs too. It's not commonly done and is a bit clunky compared to returning a tuple, but it is possible.

What's the difference? My understanding is as follows: A struct is a tuple. It's just some structured memory. Where a tuple would be indexed numerically, a struct is indexed with names of the fields (equiv in Python to NamedTuple)

What happens under the hood would be the same, but in C you have to define a new struct for each return type which is clunky. In ML or Python you can return ad hoc tuples, eg:

    let res, _, _ = fun_which_returns_3_tuple ()

    struct my_result { int res; int other; int third; };
    ...
    struct my_result r = fun_which_returns_struct ();
    printf ("%d\n", r.res);

Tuples can pull their contents from different memory locations whereas structs are laid out continuously in memory (modulo padding if enabled). Of course you could store pointers in the structs you return but that would defeat the whole 'single return' concept, then you may as well return a pointer to a struct which is ugly because it will never be thread safe and is a particularly nice pitfall regarding ownership of that struct.

So either return the whole struct as values or, alternatively - and this is the way most library functions do it - call the function with a pointer to an empty struct which the function then fills. That leaves the return value for error status.

> So either return the whole struct as values or, alternatively - and this is the way most library functions do it - call the function with a pointer to an empty struct which the function then fills.

Mind you, under the hood all your structs will be returned through pointers to caller-allocated memory, unless it can fit into 8 bytes.

“To return a user-defined type by value in RAX, it must have a length of 1, 2, 4, 8, 16, 32, or 64 bits. [...] Otherwise, the caller assumes the responsibility of allocating memory and passing a pointer for the return value as the first argument.”

https://docs.microsoft.com/en-us/cpp/build/x64-calling-conve...

Yes, but that's literally an implementation detail and this could be done in many different ways. The idea here is to gain some amount of expressiveness, if that is the goal then implementation details should be of lesser importance.

Moving structures around 'by value' rather than 'by reference' is wasteful in my view, but if you have to then you should no longer worry about the underlying mechanism until optimization time rolls around.

> Tuples can pull their contents from different memory locations

I'm not sure what you mean by this. Tuples are typically isomorphic to structs with unnamed fields.

> It's not commonly done

It’s really rather common eg several time or socket functions take a pointer as « output parameter », fill it and return an error code.

Not the best but not the worst either.

> The whole C interface is clunky because C does not support multiple return values.

C has pointers which can easily enough be used as "out parameteters". In fact the C standard library regularly makes use of these. It's not amazing, but it works fine, and it's usually fairly easy to go back and forth e.g. expressing a stat(2) call is reasonably straightforward.

However there is no way to know that programatically, and no standard way to annotate it either. So in FFI / language bindings context this is really tedious to work with.

well most of the time the return value is just an error integer, while the real return value is a pointer parameter.

My hot take here is that multiple return values are a conceptually complex way of handling tuple return values.

The C API could do this, it just doesn’t.

The Unix API even returned a pair of file descriptors for the pipe syscall. Most ISAs have a way of returning multiple values eg for structs by value. However they fell out of fashion, I think only NetBSD still has a multiple return pipe on some architectures.

The issue here is the interface to the operating system, which should be as universal as is feasible. Having multiple return values would work against that, just as using macros does.

Are you sure its not the other way around? Might C not have return values because of the systems it ran on? How would that work today in Linux, for example? Map a page to have some memory shared between the kernel and userspace?

"Should" is as wobbly as errno, no?

> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

That seems a defensible definition, but also at odds with your usage:

> More advanced languages should not be forced to deal with it

(I'm more in agreement with the definition you offer than your usage.)

Just a tick-- the quoted usage and the definition appear to be from two different people.

Reply on news.ycombinator.com