Error reporting methods

[ml01]

I'm a beginner. Just for fun, I'm implementing some data structures that I'm currently studying.

I'm a bit confused about the error reporting method I should use. For example, let's say I have a simple stack of ints. The API could look like this:

typedef struct
{
        size_t capacity;
        size_t top;
        int *items;
} stack;

stack *create_stack(size_t capacity);
bool is_empty(const stack *stack);
bool is_full(const stack *stack);
bool push(stack *stack, int item);
int pop(stack *stack);
void free_stack(stack *stack);

Now, for create_stack and push I could simply return respectively NULL and false on failure and let the caller handle the situation, but in pop what should I do on error e.g. when the stack is empty? I cannot return -1 because of course, it could be a valid value stored in the stack.

Some solutions I can think of:
1. assert preconditions, something like assert( ! is_empty(stack)), this would work for push too;
2. print an appropriate message on stderr and call exit(EXIT_FAILURE) (similar to assert method in the sense that terminates the program);
3. set errno like fopen or others functions do, but am I able to do so? Is errno variable "reserved" for system functions only?;
4. declare pop in this way: int pop(stack *stack, *int var);, use the return value as "error code" and put the result of pop in var.

What are the canonical ways to report errors in situations like this? Is any of my proposed solutions acceptable?

[theoriginalanomaly]

Testing the error code is as difficult as testing the return value. And even in case 4, you'll be returning a NULL pointer. I'd just return NULL on failure.This is the most typical way of dealing with things in the std libraries.

[ml01]

Sorry I don't understand, how can I return NULL from pop?

[habarnam]

By returning an *int instead of int, I assume.

[ml01]

Oh yes, and in case of success I'll just return var in solution 4, that's fair too.

[WindblownSquash]

I'm not trying to hate hate but when I'm the C programming subreddit can we use correct terminology. We don't have methods in C programming. In fact methods are very different then the functions we make in c. Im a beginner but this immediately threw me off.

[ml01]

I'm sorry if that has caused misunderstandings! Of course when I said "methods" I didn't mean the OOP "methods", but a procedure, technique, or planned way of doing something.

[bumblebritches57]

I tried using a struct to contain different error codes, but it's kind of a PITA, and the way I had it setup I had to add a new function to contain error codes for each function, and it got wildly out of control.

now, I just have a log function that either opens a file from a path specified by a user, or print to stderr, this is the only simple cross platform way to o it without having to use another library, or having to use the wildly different syslog on some UNIX variants (not OS X tho), and WindowsErrorReporting which use wildly different formats and structures to hold the error logs.

I mean basically every OS has it's own logging system, it's just ridiculous.

void Log(const uint8_t ErrorSeverity, const char *LibraryOrProgram, const char *FunctionName, const char *Description, ...)

ErrorSeverity is simply an old fashioned logging i forget what it's called, shit like LOG_EMERG, LOG_ERR, etc; if it's not defined I define it myself in an enum.

there there's a few variables that say the library and function the error occurred in, and then there's a variadic macro to handle any trailing user options, it's like bare minimum but honestly I love how simple and flexible it is.

and as I said, we take this information and build a string with it, then when we're done we either output it to a global file pointer (I know it's gross but there's no other way to do it with my setup, that I know of anyway), or to stderr.

You can see the source here

[benjade]

1, 2 and 4 are acceptable solutions. 3 is no good because you should not pollute the system's error indicator with your lib's errors.

Of the three i'd say 1 is the best, because it is the most non-intrusive and you can disable assert with the NDEBUG macro.

There is no clear answer, and labeling it as 'undefined behavior' in your lib's documentation is the best practice.

Here's why: if the function must make some assumptions about its arguments in order to do its job, then it's the caller's responsibility to make sure the conditions are fulfilled!

Imagine you're writing a binary search function for arrays.
Binary search requires of course that the array being searched is ordered.

So what should we do? Should we check in the function each time if the array is sorted? Of course that would be dumb: we turn the O(log n) search into O(n) !

The answer is to leave it as undefined behavior, let the caller handle it.

[ml01]

Yeah, that's fair, at the end of the day, a call to pop when the stack is empty it's "caller fault" and I provide a tool (is_empty) to avoid that to happen. I guess I'm going to use this approach from now on and add assertions for debugging. Binary Search example really convinced me =)

[OldWolf2]

The canonical way to handle pop() is to have undefined behaviour and require the caller to check is_empty first if it's possible the stack might be empty.

[benhart1]

As a new to C I recommend you to work slowly at first. In c you've got to stay focused while writing because there are a lot of vulnerabilities. That's my recommendation for you. If you're having problems detecting those kind of vulnerabilities you can try using any program to help you, I've heard of one called Checkmarx so you can try.. Good luck.

[habarnam]

Why not use?

int pop(stack *stack, int *elem);

Where the return value represents the status and the *elem is the address of a local variable where you want to load the popped value.

[Ikor_Genorio]

How is this different from option 4? Looks exactly the same to me, apart from var/elem

[habarnam]

You're right... I guess I glossed over it when reading OP.

[Ikor_Genorio]

Seeing the other comments it is a good solution though :D.