On Thu, Dec 04, 2014 at 12:36:46AM -0800, Stefan Beller wrote: > > Your solution adds a strbuf. That helps with context and stomping, but > > loses readability and adds allocation. > > > If we changed the strbuf to a fixed-size buffer, that would help the > > allocation issue. Some messages might be truncated, but it seems > > unlikely in practice. It still loses readability, though. > > > What about a struct that has an errno-like value _and_ a fixed-size > > buffer? I'm thinking something like: > > What do you mean by the allocation being an issue? I mean that the caller has to take care of releasing the memory. This adds boilerplate to the caller, and is a potential source of leaks. > We're only populating the error buffer in the error case, so you're > not talking about performance/speed I'd assume? No, I don't care about performance here. Only code maintainability. > As error handling breaks in the least expected ways, I'd rather go > with well tested string buffer codes there? We'd still be building on snprintf. And with a known-size buffer, we can wrap the formatting so that the callers don't even have to care (see the mkerror example I posted). -Peff -- 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