Jeff King <peff@xxxxxxxx> writes: > Yes, I agree converting the integer back into a string later does not > always carry all of the data. OTOH, the caller can often supply the > context (i.e., this is basically how "errno" works). This gets back to > the idea we discussed a while ago of having a "struct error" that can > carry the code and the parameters (or if you like, the code and a > finished error message). It just feels in some ways like that ends up > with the worst of both worlds (a lot of boilerplate for integer codes, > _and_ the allocation and cleanup issues associated with a string error > message). > > I dunno. I'd be interested to see a rough draft of an idea applied to a > specific callsite. For this specific callsite, I think the error code alone is the right way forward. It conveys all information necessary out of the callee back to the caller, so that the caller, when it decides to do so later, can turn error code to human readable form. For some callsites, there may be cases where carrying a centrally produced string may be a handy way to grab detailed error message out of a deep call chain, but even in such a case, it is likely that we would need a separate error code, and a funtion that returns a pointer as its primary return value would need "two" extra out parameters, one for message and one for code. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html