𝐚𝐝𝐝𝐢𝐞 (train enjoyer)

the two ways to do this is by either creating an array on the heap (using malloc()), or (imo the better method (in most circumstances)) giving the find_divisor function a pointer to an output array, which it will fill in the values for

something like this:

void find_divisor(int* inputArray, int** outputArray)
{
     // (do stuff with inputArray[i] to solve for divisor and dividend)
     *outputArray[0] = divisor;
     *outputArray[1] = dividend;
}

int main(int argc, char** argv)
{
     int data[] = {1, 2, 3, 4, 5, 5, 6};
     int result[2];
     find_divisor(data, &result);
     // (returned array is stored in result[])
     // ...
}

a lot of the reasons for the weird quirks in C are due to how CPUs actually work x_x i've managed to internalize all the reasonings

("why can't you just return an array?" because it either has to be allocated on the stack or the heap, but the local stack is cleared when your function returns, so it must be stored on the caller's stack, or in the heap, but it has to be later free()-ed if allocated in the heap)

edit: if your class is Requiring the return type to be non-void then i'm guessing they Expect you to allocate it using malloc() but that's kinda dumb :( bleh

C is the thing that underlies all the rest of those languages. it makes more sense after you do assembly, when types get to really take off the mask and show that they're all secretly ints.

Since the array has a fixed size, you can wrap it in a struct... Dn't ask why it has to be wrapped in a struct..

struct find_devisor_result {
  int result[2];
};

struct find_devisor_result
find_devisor(...) {
  // return 1 & 2 always yes very algorithm
  return (struct find_devisor_result) { .result = { 1, 2 } };
}

(i also didn't test this code at all so it might just not work)

what's been covered in class?

They probably don't want you looking outside of what they've taught, and it's likely designed to not be too hard (early in semester)

If you will tolerate a joke answer: learn rust, solve this in rust, delete the types, and you'll see how to do it in C

Embrace the darkside. Let the madness take hold.

From what I can tell, this function takes an array of two numbers only. You allocate an array of 2 numbers on the stack, and pass a pointer to it to your function. And then you just write to that pointer within the function.

In general you never want to use malloc within a function. Ideally, you only want to allocate memory at the top scope, and pass a pointer to that memory to whatever function that needs it.

When I was doing C, I remember using structs a lot. For this assignment, probably a struct would be better.

struct two_numbers = {2, 4}
two_numbers = find_divisor(two_numbers)

The larger problem with this question is that since it is impossible to actually return a [local] array, it is unclear which of the things that are possible that it wants you to do. If I were given this question I would probably just use a static array, since that comes closest to the instructed 'return an array' without being undefined behavior.

i must have a really messed up brain cause i actually understand exactly why that doesn't work

when passing an array to a function, the function CANNOT (or hasn't been told to) make any assumptions about the array- because Any code can call this function (especially if loaded like a library), the array size is no longer a known constant like it is with a local array variable- this is why every standard function that takes in an array Also asks for that array's size, since the size of an array is not inherently included with the array (except with zero-terminated strings ("C-strings"), the zero byte marks the end of the string)

i am Very Normal for knowing this by heart :) (help)

if you do end up needing a headstart, there's also searching "c for x programmers", and Learn X in Y Minutes, Where X == C for the whirlwind syntax tour.

and if you need code examples of those things in use, while you can find others, one of the more fun ones is mining Advent of Code solutions, because then you get multiple examples (but they might not be right / the right one to use, necessarily) https://github.com/Bogdanp/awesome-advent-of-code#c

because that lets you then look up those solutions in other languages and see the similarities of approach

In most programming languages, the length of the array is a property of the array. It's stored alongside the array elements.

This is because those programming languages learned from the mistakes of C. In C, an array is just a pointer for the first element of the array. arr[4] actually means "add 4 to the arr pointer then dereference the resulting pointer". C arrays have no concept of size, so you have to pass in the size of the array separately from the array itself.

And this right here is cause of, I want to say, 80%ish of all critical bugs in existence. Hell, this was the cause of the heartbleed bug.