Tamás Nepusz

I'd say 1.0. That's what the original proposal was, wasn't it?

Note to self: the `IGRAPH_GLP_` codes are currently used with a nasty macro trickery in `glpk_support.c`: ```c #define HANDLE_CODE(c) case c: code = #c; ret = IGRAPH_##c; break; ```

Going through the list of error codes now. Concrete proposal: * [x] `IGRAPH_EINVEVECTOR` should be gone. We should use `IGRAPH_EINVVID` instead. * [x] `IGRAPH_EINVVID` should be kept. It makes sense...

Note to self: the usage of `IGRAPH_ERANGE` vs `IGRAPH_EOVERFLOW` to indicate conditions when the vertex or edge count is too large (or would be too large) is not consistent even...

> Can we also merge these two and use it with all kinds of arithmetic over/underflows? Shall we simply use `EOVERFLOW` for _under_flows? > `ERANGE` could be kept for cases...

> I'm concerned about how much this would limit supporting multithreading in the future. We make the underlying variable thread-local (similarly to how `errno` is thread-local in C). Or we...

My idea with the ARPACK error codes is moot; ARPACK does not have a common set of error codes. Each ARPACK function uses negative numbers to report errors, but they...

Three things left: * Dealing with the ARPACK error codes. * Dealing with the GLPK error codes. * Dealing with `IGRAPH_ENOSOL`. W.r.t `IGRAPH_ENOSOL`, I'm waiting for feedback from @szhorvat ....

> ENOSOL is used for Eulerian graphs only. Let's replace it with EINVAL I've checked the project history and it seems like we actually replaced `EINVAL` with `ENOSOL` between 0.10.1...

I decided to leave `IGRAPH_ENOSOL` in the codebase. It looks silly if we remove it now after adding it in 0.10.2 :-D