Derek Martin wrote: > On Mon, Dec 01, 2014 at 11:00:11AM -0800, Kevin J. McCarthy wrote: > > In general, mutt checks NULLs pretty well, but returning NULL from > > mutt_substrdup() isn't without risk of just generating a segfault in > > another place. So personally I would vote for the second or third > > choice. > > Returning NULL from something that allocates memory is always a good > (and I dare say the best) option. It's the standard behavior of all C > standard memory allocators, and if the caller crashes on NULL > dereference, in general you will know EXACTLY where the problem is. > Your function could also make use of errno (setting it for instance to > ENOMEM or EINVAL) to further clarify what actually went wrong.
Note that mutt's safe_malloc() exits the program when an allocation error occurs though. That said, this isn't really a memory error, but bad input. How do deal with that is up to the project standards. Poking around lib.c, I do see other functions such as mutt_concatn_path() that return NULL on bad input, so it may be consistent and fine to deal with the error that way. Since this particular error has occurred in the past, my thoughts were leaning towards aborting or stopping the error from causing a segv. But you do have a strong point about standards, historically, and other examples inside mutt. -Kevin
signature.asc
Description: PGP signature
