| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 11, 2010 0:30 UTC (Thu) by charlieb (subscriber, #23340)In reply to: Glibc change exposing bugs by donwaugaman Parent article: Glibc change exposing bugs
> Hmm... the man page on my desktop computer (RHEL4) says:
What manpage is that? The memcpy(3) manpage on my CentOS4 box does not say "the behavior is undefined". Ah, I see that the memcpy(3p) one does.
> 'must' and 'should' are more in the vein of RFCs.
OK. But at least those are clear. "should" in the context of an API man page is not.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 11, 2010 12:23 UTC (Thu) by gidoca (subscriber, #62438) [Link]
> OK. But at least those are clear. "should" in the context of an API man page is not.
If "should" is interpreted the way you do, then they might as well have omitted the sentence.
Glibc change exposing bugs Posted Nov 11, 2010 18:03 UTC (Thu) by donwaugaman (subscriber, #4214) [Link]
memcpy(3) on the same RHEL4 box says:
"The memory areas may not overlap."
... which sounds a little stronger than "should" to me.
Not sure why CentOS4 differs...
At any rate, arguing over the man pages is irrelevant to the standard - if the man pages don't match the standard, the man pages need to be fixed rather than the standard.
That being said, it would sure be nice to have some kind of formal deprecation of the previous behavior. One of the nice things about the free software world is that it should be more possible to make these kinds of changes because it's easier to change the programs whose assumptions worked OK with the previous behavior but are violated by the new behavior. Of course, with closed-source Flash players, that goes out the window, and it becomes a question of whether it is more important to pacify Adobe users or to give Adobe an incentive to clean up its software.
|
|||||||||||||