tags 509963 fixed-upstream thanks, On Tue, Jan 13, 2009 at 6:10 PM, Marc Lehmann <schm...@schmorp.de> wrote: > On Tue, Jan 13, 2009 at 05:05:22PM +1300, Michael Kerrisk > <mtk.manpa...@googlemail.com> wrote: >> The strtok() function uses a static buffer while parsing, >> so it's not thread safe. Use strtok_r() if this matters to you. >> >> Tht is your view about the worts problem. But, the strsep() page >> emphasizes the what *it* considers the worst problem: > > This is of no relevance: > >> This function suffers from the same problems as >> strtok(3). > > This is wrong, regardless of what I, you, or the manpage considers the worst > of them, the fact is that strsep does not suffer from the same probelms as > strtok. > >> So, I'm not (yet) convinced that anything needs fixing. > > The statement is trivially false, because strsep does NOT mention from the > same problems as strtok, as even you pointed out. > > Regarding what the biggest problem is, baiscally everybody in existance > agrees that the worst problem is the static buffer, but thats not relevant > to the bug in the manpage: That the strsep manpage doesnt consider it the > biggest error of *strsep* is obvious, because strsep _doesn't_ suffer from > that problem at all, which is exactly the problem I am describing. > > So the manpage is even more confusing, and all my points are correct and > do apply. > > Note that I don't care about whether you are convinced or not. The manpage > is buggy, and if you can't see that, that's your problem. I know that it > is wrong, and it doesn't affect me. Whether you or anybody else wants to > _do_ soemthing about the bug is not relevant to me. > > Greetings, and there is no need to talk further about this topic from my > side.
Why such an unpleasant tone to your response? I was (quickly -- because my Inbox is very long) trying to get some further clarification on the issue. Your bug report was somewhat vague. If you had started out by saying something like: "The strsep(3) page says that that functions suffers the same problems as strtok(). But that's not completely accurate: the strtok() page lists 4 problems with that function, but the last one of those problems (static buffer), does not apply to strsep(). Furthermore, the last problem is IMO the most important one afflicting strtok(). So I suggest the following amendment to strsep(3)..." that would have made the report more useful. As it is, I had to go away and deduce the details and consider whether a fix was worth the effort. For what it's worth, for man-pages-3.17, I made the change below to strsep.3. Cheers, Michael --- a/man3/strsep.3 +++ b/man3/strsep.3 @@ -75,10 +75,14 @@ However, .BR strtok (3) conforms to C89/C99 and hence is more portable. .SH BUGS -This function suffers from the same problems as -.BR strtok (3). -In particular, it modifies the original string. -Avoid it. +Be cautious when using this function. +If you do use it, note that: +.IP * 2 +This function modifies its first argument. +.IP * +This function cannot be used on constant strings. +.IP * +The identity of the delimiting character is lost. .SH "SEE ALSO" .BR index (3), .BR memchr (3), -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
