Hi Joseph, At 2026-07-31T22:42:00+0000, Joseph Myers wrote: > Standards involve accepting agreed compromises that might not have > been your first choice, rather than endlessly relitigating past > disputes without new evidence or changed circumstances. In this case, > the choice of where to put the functions in C89 was an agreed > compromise that implicitly obsoleted the previous location, and should > have put an end to any arguments that <string.h> was a bad location > for those functions in the absence of clear new evidence. We have > plenty of clear evidence for confusion about strn*; we don't about > mem*.
What are some good ways to gather evidence that: * ...C programmers since 1989 have gotten better at recognizing when they're dealing with "memory buffers" versus "strings"? * ...that the header file's name has aided or frustrated that recognition process? * ...that consequences of whatever confusion persists are more severe than the C Committee measured in 1989? You can tell by my phrasing which way I _suspect_ the evidence points, but I'll openly admit I don't have quantiative data. But I think bringing such information to bear makes a stronger case than a simple appeal to 37 years of precedent. Occasionally, matters get relitigated because they had been wrongly decided. I appreciate the trend since 2000 or so of Stroustrup (with respect to C++) and the Austin Group (with respect to POSIX) becoming more open about where the bodies are buried, and how certain standardization decisions have been reversed (through deprecation, withdrawal, and similar) because a powerful vendor took its leave and was no longer around to filibuster constructive development until its demands were met. I seem to recall Stroustrup calling out Sun Microsystems by name in the 4th edition of his main C++ book. (Something to do with the exception propagation mechanism, I think.) I suggest to WG14 that a good way to reduce relitigation is to candidly disclose in informative sections of the standard corresponding to applicable topics, where the committee as constituted at the time of issue has reached exhaustion with a matter. (Though I wonder if ISO would insist that such language be ripped out.) I followed the C23 standarization process closely, and it looks as if the National Bodies (NB) very nearly fought WG14 to exhaustion regarding trigraphs. I was greatly relieved that you guys won that one. Back to the topic at hand, in data processing we tend to strongly distinguish three forms of storage management: 1. base and bounds (mem*) 2. delimited (if with null bytes, str[^n]*) 3. fixed-field (strn*, but not very consistently) From one perspective, 1 and 3 are really the same, but from another they're not, because, as some thousands of CVEs have shown, programmers thinking of case 3 tend to assume that the field will be populated with elements that are "well-behaved" in some way, whereas in case 1 they tend even more strongly to be conscious that the storage could be populated with arbitrary or even malicious garbage. Do your impressions match mine in this area? Regards, Branden
signature.asc
Description: PGP signature
