Note that these settings don't really work for the other binaries since main gets redefined.

Can you explain the frontend part of this?

frontend in this context means an implementation of main that accepts arguments in a way that AFL can integrate with. Should I expand on the comments for this option?

Does this make sense? Would we miss cases for uncompactCells that can't be generated by the output of compact?

A second run of uncompactCells is done below, using the original input data. Not sure if this additional run of uncompact on the compact output is needed but it seemed like a reasonable check to append.

We don't need the error here?

Correct. I consider failing and returning the appropriate error code acceptable behavior. Unacceptable behavior would be undefined behavior, faulting/crashing/out of bounds reads, etc.

Edit: Oh, I see we use the output of this function later. In this particular case I don't think it's too bad since we are guaranteed that the memory pointed to by compacted has been zeroed by calloc. If this were data on the stack using it in a potentially unintialized state could be bad. I will update this one to check the error code.

For my info - it seems like there's a class of issue here where the user passes in an array and a size that don't match, and we get an invalid array access. Since we can't deal with this (we don't know the array size), are we assuming this is outside the bounds of testing, and is user error? Since this is a pretty serious error, do we need to indicate where users might need to be careful in their own code not to hit this?

This is a serious issue with memory management in C. I considered this case to be out of scope for the fuzzers since I don't know of any way to make H3 resilient to this kind of error.

We should be careful to document the expected array sizes when users pass memory into H3 so this can be correctly implemented on the user side.

For my info - why memcpy here and casts in the other tests?

This is needed because we modify args.str on the next line to ensure it meets the contract that it is null terminated. This cannot be done on the original buffer because of const and because libfuzzer will complain.

Worth a comment in that case I think

Will add. Come to think of it we may wish to address this in the API of stringToH3 by passing the buffer length.

I'm confused here - should this return 0 and exit? If not, why print the error?

As it is it will crash on line 57. Not sure if this will be relevant after #551.

I'm quite confused here - isn't the fuzzer only going to provide sizeof(inputArgs) worth of data? Where does the rest of the data after offset come from in that case?

I will need to check if this will work with AFL (might need to adjust the seed file so it has data after inputArgs). For libFuzzer it does not know about inputArgs so it will generate larger test cases.

This is probably just a reflection of me not knowing how fuzzers work, but when you're doing multiple sequential tests like this, does it become harder to test the last function because you need to "get past" all the previous ones? Is there any value is splitting out each function separately? But that's also a lot of annoying boilerplate...

It's correct that if any of the previous functions called were to crash, this function wouldn't be exercised. But in that case we'd still have found a crash warranting investigation anyways. If we explicitly terminate the fuzzing run before reaching this function (i.e. if getNumCells were to return an error then we return 0), then that would not be a good test because this function's invocation would be dependent on the previous function. (And that is not part of the contract of calling this function, as with the memory allocation size functions.) That doesn't happen here so I believe this is a valid exercise of all the functions in this file.