> I kind of agree with your sentiments (having been bitten by that myself when > logging stuff), but I investigated it at the time and GSFormat.m is right and > your code is wrong. > > The reason is that the %s format deal with a nul terminated c-string > argument, and by definition that's *not* an array of char whose length is > determined by the precision of the format string, the nul terminator is > *mandatory*. If you code passes an argument which is not nul terminated than > your code is doing something illegal and you can't really complain about > *anything* that happens. > Also, the precision in the format works in conjunction with field width and > alignment ... the format code needs to determine the length of the string you > passed (using strlen) when it decides which part of the string to use ... so > in the case where the rightmost part of the string should be displayed, using > the precision as the length would give the wrong result. > > We could probably adapt your patch to use precision as string lengh in those > cases where it will work, but you can't catch all cases that way ... so maybe > it's better if people find out as soon as possible that c-strings have to be > nul terminated. > > Sorry about this ... but it's a behavior inherited from the C stdio library > and posix etc standards. My own feeling is that format strings *ought* to > provide some way of working with unterminated strings, but they just don't, > so you have to copy the data into a big enough buffer, add the nul > terminator, and use that buffer intead of the original data :-(
Interesting, I've never read the actual standard, my copy of K&R (2nd ed.) just says (in table B-1); 's' char *; characters from the string are printed until a '\0' is reached or until the number of characters indicated by the precision have been printed. So by from the way K&R reads it is a bug. No idea about POSIX et. al. though. I find it humorous that my book opened to exactly that page and I haven't looked in there in quite a number of years. Chris. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev