All

Significantly increased the original (originated from me) estimate. This cannot be done as a simple mechanical task, but the code must be carefully analysed before making modifications. This walks hand in hand with MXS-253.

Lowering priority to minor.

Not using strncat the way it is supposed to be used is clearly a bug, but given that this usage has been in MaxScale from the start, it is not likely to start causing crashes now. The buffers are most likely big enough so that the potential problem does not manifest itself.

This is better handled as as part of the general refactoring to be done post 1.3.

Moving to 1.5.

Moving to 2.1.0. In many places strncat is used correctly and where it isn't, it does not seem to cause a problem.

However, even if strncat were technically correctly used, its use would still be questionable. The correct use of strncat will prevent a buffer overrun, but if the buffer is too small it seems that in most cases you'll end up with an unusable result. So, if it cannot be certain that there will be enough space, that should be checked explicitly and if there isn't an error should be generated. And if it is known there is enough space, there is no reason not to use strNcpy.

The strncat usage has been reviewed and corrected were necessary.

The remaining strncat usage appears correct, although is somewhat dubious.