Reasonable way to implement "safe" math operations using _Generic?
Very impressive! A few notes:


I really like how you are using C11 stuff.


#define safe_add(x, y) _Generic((x + y),                    \
                            unsigned int: safe_add_uint,    \
                           unsigned long: safe_add_ulong    \
                       )(x, y, __FILE__, __LINE__)



It's good that you are using the more modern items the C standards have given us to use.  My only nitpick with this #define is that your aligning is a bit off.

#define safe_add(x, y) _Generic((x + y),                        \
                                unsigned int: safe_add_uint,    \
                                unsigned long: safe_add_ulong)  \
                                (x, y, __FILE__, __LINE__)

@Morwenn touches on your error handling a bit, but I want to go deeper.  For now, I want to talk about the style of error reporting I've come to adopt for such APIs. Options for error reporting from C functions include the following:


Return an error code from functions that can fail.
Provide a function like Windows GetLastError() or OpenGL's    glGetError() to retrieve the most recently occurring error code.
Provide a global (well, hopefully, thread-local) variable containing the most recent error, like POSIX errno.
Provide a function to return more information about an error, possibly in conjunction with one of the above approaches, like POSIX's strerror function.
Allow the client to register a callback when an error occurs, like GLFW's glfwSetErrorCallback.
Use an OS-specific mechanism like structured exception handling. 
Write errors out to a logfile, stderr, or somewhere else.
Just assert() or somehow else terminate the program when an error occurs.


There are loads of tradeoffs among these options, and it's a matter of opinion as to which ones are better than others. Like all matters of style, unless a style is just plain unsuitable (like the last two options above might be for many uses), it's probably most important to apply the style you choose consistently.

Let me illustrate the style of error handling I use for C APIs with the following re-written function of yours:

unsigned int safe_add_uint(unsigned int x, unsigned int y,
      const char* filename, int line_num, char* error)


Where we call it as:

char* error = /* allocate memory */;
safe_add_uint(x, y, __FILE__, __LINE__, &amp;error)`


Now your function can set the value of error within the functions, and then print the output in something such as an atexit() function.

You might think that this could be a bit cumbersome for an error handling system in C, but here's the catch: this C error handling style that plays nice with C++ exceptions too.  This can be nice when implementing an hourglass API.
You should probably be using exact-width integer types.
Always declare what parameters your function takes in, even if nothing.

int main(void)


You might wonder why we have to do this.  Imagine we have the function foo() declared as such:

int foo()


In C, this is known as an identifier list and means that it "can take any number of parameters of unknown types".  We can actually pass values to the function even though we don't mean to or intend to.  If the caller calls the function giving it some argument, the behavior is undefined. The stack could become corrupted for example, because the called function expects a different layout when it gains control. 

Using identifier lists in function parameters is depreciated.  It is much better to do something like:

int foo(void)


In C, this is known as a parameter type list and defines that the function takes zero arguments (and also communicates that when reading it) - like with all cases where the function is declared using a parameter type list, which is called a prototype.   If the caller calls the function and gives it some argument, that is an error and the compiler spits out an appropriate error.

The second way of declaring a function has plenty of benefits. One of course is that amount and types of parameters are checked. Another difference is that because the compiler knows the parameter types, it can apply implicit conversions of the arguments to the type of the parameters. If no parameter type list is present, that can't be done, and arguments are converted to promoted types (that is called the default argument promotion). char will become int, for example, while float will become double.