On Nov 1, 2014, Torvald Riegel <triegel@xxxxxxxxxx> wrote: > It's not surprising that this matters today (ie, when you made the > choices), and it's not like we've been aware of this since just > yesterday. > That's why I'm arguing for being conservative That goes both ways. While strcpy coded for current standards might wish to make such optimizations, old code written for earlier standards that did not make allowances for the proposed strcpy optimization would break. So we have to be conservative in strcpy to avoid breaking valid old programs (per the standards they were written for), and this implies not making the proposed optimization, which brings us back to the conclusion that the ctermid(NULL) implementation is MT-Safe. And AS-Safe, too. > it helps to be cautious when making assumptions about things that may > easily change in the future and that you can't predict. Per the above, this one property of strcpy is not one that can *easily* change. Quite the opposite. It takes a lot of wording contortionism to make writing garbage fit into the strcpy contract even under current standards. > In our case here, if you feel like what you require from the strcpy > implementation is very complex I don't. The requirements are the common requirements that apply to all historical standards that have specified strcpy. Nothing beyond that. Now that's not much of a strong or surprising assumption, is it? > Or, don't go for specifying assumptions about strcpy in the ctermid > docs, but rather try to solve it at the other end by documenting that > strcpy has to work well under concurrent execution, in particular under > concurrent but "idempotent" copies to a memory range. My take is that requirement is already coded in early C standards.c -- 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
