Hi Branden, > I have a patch that quiets the sized-deallocation warning, but the > most obvious solution (to me) causes a different warning.
That I don't think you give? Can't the new delete call the existing one to do the work? Whilst reading http://git.savannah.gnu.org/cgit/groff.git/tree/src/libs/libgroff/new.cpp ... void *operator new(size_t size) { // Avoid relying on the behaviour of malloc(0). if (size == 0) size++; That's a shame as programs like valgrind will now know there's a writable byte so won't catch code writing to the address from malloc(0) in error. char *p = (char *)malloc(unsigned(size + 8)); This could overflow, allocating, say, four bytes instead of the large size requested. if (p == 0) { if (program_name) { ewrite(program_name); ewrite(": "); } ewrite("out of memory\n"); _exit(-1); This is equivalent to _exit(255) and thus looks equivalent to dying from signal 127 when accessing the calling sh's `$?' variable. Also, shells use high unsigned seven-bit values to indicate problems like `command not found' so most programs should just exit with 0 or 1, with small values in particular documented cases. } ((unsigned *)p)[1] = 0; Let's hope int is never eight bytes as that would then write beyond malloc(1)'s area. :-) memset(p + 4, 0, 4), or uint32_t if groff uses those, might be better. return p + 8; } -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
