On 2014/7/26 03:33 PM, Chen Gang wrote: > On 07/26/2014 02:32 PM, Chung-Lin Tang wrote: >> On 14/7/26 11:28 AM, Chen Gang wrote: >>> The related strncpy() for custom_builtin_name[*] may set 5 none-zero >>> characters, which may cause custom_builtin_name[*] is none-zero >>> terminated. >>> >>> So add additional '\0' byte for custom_builtin_name[*]. >> >> Where did you see this? Supposedly the snprintf of the custom function >> type string should at most be of 'xnxx' format; 4 characters at most, > > I guess, your 'xnxx' means "%cn%c%c", not "%sn%s%s" (which is current > implementation), also at present, "32 - n" is 17, not 4 for snprintf() > length limitation.
The use of %sn%s%s is intentional. That allows me to print "" directly using snprintf. '32 - n' is to represent the rest of the 32-byte buffer, harmless really, as it is at most 4 chars. Also, if I were to restrict it in the snprintf argument, it would be 5 (including the null char) not 4. > If we are always sure it must be no more than 4 characters (at present, > it is, but in the future, I don't know). We can use strcpy() instead of > strncpy() for it -- that will let other readers no doubt. > > If we need let custom_builtin_name[*] not only zero terminated, but also > zero pad, we need pass '4' to strncpy() instead of '5', that also will > clear all doubts. I don't understand what point you're trying to make here, really. As Andreas has noted in the other mail, strncpy does zero-termination automatically. Chung-Lin >> not 5. Do you have a test case where the behavior you described appears? >> > > I find it by reading source code, for me, it is simple code, test is > welcomed, but not mandatory. > > But it really needs necessary discussion (for modification, and comments).
