Issue #3395: Fix tool table formatting error with random tool changer

[andypugh]

Issue introduced in 088be31

[smoe]

strncat "appends at most ssize non-null bytes from the array pointed to by src". It does not check how much is already written to the string or how large the buffer truly is. So, the length of formatted_line in my understanding needs to be substracted from CANON_TOOL_ENTRY_LEN-1 to be safe.

This is all a bit cumbersome. I suggest to not execute the strncat in line 241 and instead keep the value "tmp" intact by not overwriting it in line 273. Instead, in line 273 perform the snprintf into formatted_line and check the number of characters written. Like this:

new line 273:

int charsThatWouldBeWritten snprintf(formatted_line,CANON_TOOL_ENTRY_LEN-1,"%s ;%s\n", tmp, tdata.comment);
if (charsThatWouldBeWritten<0) {
    fprintf(stderr,"Could not be printed. No good. Maybe this computer should not control any machine.\n");-1
if (! charsThatWouldBeWritten<CANON_TOOL_ENTRY_LEN) {
    fprintf(stderr,"Ouch! May still be ok if the bits up the comment were copied. Not checked.\n");
}

and analogous for the part just attaching the "\n".

This would somewhat guarantee that all non-comment bits are truly read - This may avoid some weird situation to have some tool's length shortened by a couple of decimals positions and nobody notices that. Admittedly, after a quick check on http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolTable it seems unlikely to create such a long line.

The code does not check if strlen(tdata.comment) < CANON_TOOL_COMMENT_SIZE . This would allow the routine to create formatted lines that do not follow the constraints set by the format.