Hi Robert, > ps: often "easier to audit" means "presumed better" which means > "investigated less stringently" which leads to "unsafe". There's no > shortcut to actually doing the work.
The "short-cut" is to have dynamically-growing strings and arrays generally, and use those in many cases where the little extra CPU doesn't matter. "doing the work" would still be required though in moving over to it, and it may introduce memory leaks by free()s being missed initially. Having asprintf(3), for example, can make the code read at a higher level than the tedious-after-a-while style of checking through the code paths to make sure the array is big enough in all cases, including popping down into called functions. Don't things like http://www.gnu.org/software/gnulib/ and http://gcc.gnu.org/onlinedocs/libiberty/ remove some of the pain of common non-POSIX functions, e.g. asprintf()? We're probably all used to reading higher-level code than nmh's C in languages like Python and Go. Their logic tends to be clearer because the noise of housekeeping is largely removed. nmh's C could be elevated too given a few convenience routines that could be used in all but the most inner-loops. Does anyone run the test suite using valgrind(1)? :-) Cheers, Ralph. _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
