On Oct 30, 2014, Torvald Riegel <triegel@xxxxxxxxxx> wrote: > On Thu, 2014-10-30 at 16:24 -0200, Alexandre Oliva wrote: >> >> > The hardware requires synchronizing accesses, and just the mere presence >> >> > of a data race may lead to undefined behavior of the program. >> >> Sorry, but “undefined behavior” is standardese for “don't do that”. > It's don't do that for a reason, not just don't do that and you'll be > fine. Yup. But remember, it's users of the standard we implement that are not supposed to do that. We can and often do get away with such stuff as part of the implementation of the standard. There's a long history of doing so: remember when we implemented mutexes without standard atomics? Nowadays, you might look at them and find those implementations disgusting, and think “how the heck nobody thought of documenting the reliance of this code on certain memory model properties that no longer hold?” The obvious answer is that, back then, such properties were perfectly normal and they had no idea something else might take over in the distant future. The point I'm trying to make is that there's only so much future-proofness you can put into this sort of documentation. The most difficult bits to document are not those that are surprising as of the writing of the docs, but those that are blatantly obvious to pretty much anyone at that time, but that over time become surprising. Historians run into lots of walls related with this sort of implicit knowledge of a time. > Please try to understand the issue. I do. It's very clear to me. You wanted and hoped me to do a lot of work that I was not supposed to do, and I didn't do it, in part because I have little hope of seeing the future as well as you claim to be able to. > How is that supposed to work if you haven't documented all the > assumptions you made (i.e., if ctermid is not just an outlier)? It is, but if I were to document all the assumptions I made, I'd have to write several books of assumptions, encoding all the knowledge I've accumulated about how past and present hardware architectures work, any one of which might change in future architectures. > Should I review all the code again? Sure! Clearly you're not happy with the annotations and comments I made, so I don't see another way to go about it. > you didn't seem interested back then. There's a huge difference between being interested and being pragmatic about fulfilling one's assignment from up the management chain, rather than doing somebody else's work while slowing down one's own. > You said elsewhere in the thread that you have no other information than > what's in the manual ... and what we covered in earlier discussions. > what assumptions you made beyond the contracts of functions Heh. It's almost funny that you talk about the contracts of functions, when you yourself claimed their definitions were not clear enough to figure out what the precise requirements were. Please make up your mind about that point before wasting more my time, will you? -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
