On Sat, 2014-11-01 at 16:32 -0200, Alexandre Oliva wrote: > 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. Which earlier standard are you referring to? Did any old standard have strcpy as something else than a sequentially-specified function? > 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. No it does not. Sequential specifications for functions are before invocation / after invocation rules -- how the function does it is not restricted, especially if all it does is write to the destination string, in some way. It is not specified as operating on volatile-qualified data, so C as-if rule applies. Same for compilers. If, for a piece of sequential code, the compiler can prove that a location will be written to, then sure it is allowed to write a speculative value early, for example. There's a reason we have the volatile qualifier and it's not the default. > > 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 > They didn't specify rules for multi-threaded execution, did they? There's volatile, and the as-if rule, but the latter really allows stuff like speculative writes. -- 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
