you don't need to do that tho

There is no point in checking the return of malloc() on Codewars, because you are given no instructions on what to do if it fails. In large C projects, error handling is usually centralized and malloc() and other system calls are usually wrapped in a function or macro that handles the potential failures. But what to do in case of failure is specific to each project and to each system call: sometimes you want to exit the program immediately, sometimes you want to try and recover the error, sometimes you want to ask the user how to proceed.

On Codewars, your code run in a Docker container and the docker image will be shut down when the tests are over, regardless of whether they crashed or not. So whatever error handling the user performs in their code is ultimately irrelevant.

On another note: on some systems and with a certain configuration, malloc() does not necessarily return NULL when it does not find enough memory to give you; instead, the operating system will pretend like it did, in the hope that either you won't access all of it, or that it will manage to free some memory from other processes to give it to yours by the time you actually access it:

https://stackoverflow.com/questions/16674370/why-does-malloc-or-new-never-return-null

Often the description says something like "You can expect the input to be valid".
Since it is missing in this case the top solution should indeed include sanity checks/error handling imo.

I am commenting here, since it is the top solution. Is it habitual on Codewars not to take care of failures of system calls? No one seems to do it however, for example here, the program will collapse if malloc() fails and returns NULL.

I do not think efficiency matters a lot here since we are dealing with an input of constant size (the chessboard – always 64 tiles).

The possibility of a jagged matrix (i. e. lines of variable length) defeat the concept of "instructions scattered over a ‹two-dimensional plane›". It would only make sense to receive the input as a 2D matrix (i. e. a list of lists of fixed length).

I used BFS too and did not have an issue with time. After all, BFS has the best possible time complexity for a graph searching algorithm.
There may be a little bug that causes your solution to loop endlessly.

If you are a beginner, please, be informed, that while these one-liners may look "cool", this is not what you want to do.

What is the point of the format of the test cases? Why have the lines be joined with '\n' when we are going to parse them into a matrix anyway?

What was I thinking? Why store it in a variable when you can just use ord('a')...

i agree, although this solution may appear as clever it doesn't resemble the best practices.

Declaring what the type of 'maze' is would be nice. Also, I see most (if not all) solutions split the string into lines by '\n'. A list of lists (or at least list of strings) is easier to work with and makes much more sense in a task like this.

The idea is that no number from the interval (n/2, n) will ever be a divisor of n.

Thank you for the explanations. I think that I am getting a bit closer to understand all of this.

You are almost correct, however, we need to be careful about how we simplify the equations. The time complexity of making a single slice is (omikron) O(n). Making two of them, theoretically has a time complexity of O(n + n = 2n). Note that we are adding, not multiplying. Since 2 is a constant, we can omit counting it. (In other words, the functions n and 2n grow at the same rate.) Just making the slices has therefore a time complexity of O(n).

This happens for every element, so we then multiply by n and get O(n²).