streambuf performance 200x

[Nathan Myers]

On Fri, Feb 14, 2003 at 10:48:33AM -0700, Martin Sebor wrote:
> Nathan Myers wrote:
> >On Thu, Feb 13, 2003 at 04:15:30PM -0700, Martin Sebor wrote:
> >... Appendix D 
> >was supposed to reconcile existing practice, making a spec that was at
> >least consistent, if not "right".  It's *deprecated*, in the "Backward
> >Compatibility appendix.  Adding extra stuff that legacy code doesn't 
> >depend on is doing too much.
> 
> I'm not suggesting that anything new be added.  If the text requires
> or even recommends (if non-normative) behavior that doesn't make
> sense or is unintended, the best way to reconcile it is, IMHO, to
> change or remove it. Just leaving it there is misleading not only
> to implementers, but to test suite writers as well. 

If it's non-normative, then a test suite had better not require it.

Still, I agree, confusing or misleading non-normative text should be 
fixed.  Andy can do that on his own initiative, although he likes to 
have guidance from the WG.  If the change ended up changing normative 
requirements, that would exceed his authority.

> I would rather
> err on the side of stricter conformance than to have to defend
> our implementation after another damaging Conformance Roundup.
> Please realize that not everyone has the historical insight of
> knowing what may have been the intent almost a decade ago.

Ask!  If the text doesn't make it clear, the text needs to be fixed.
We don't know what to fix if nobody speaks up about what is confusing.

> >The note is meant only as an aid to describing 
> >what the normatively-specified interfaces do.  If *they* don't say 
> >it, you shouldn't do it.
> 
> If I'm free
> to ignore the Note completely, then the constant bit means nothing
> and overflow() is free to write all over the buffer. In fact, since
> the behavior of overflow() itself is described in D.7.1.3. p3 by
> non-normative Notes, palloc becomes meaningless as well. I think
> you would be shocked if the palloc argument ended up being ignored
> by an implementation of strstreambuf no matter how fast it was.

Since the text describing allocation using palloc is normative,
the behavior is certainly required.  The non-normative note defines 
a shorthand, so that the normative text can say "palloc" instead of 
"the palloc_arg value that was provided as a constructor argument, 
or 0 if there was none".  You aren't free to entirely ignore 
non-normative text, because it defines terms that are used to describe 
conforming behavior. 

I think maybe you misinterpret what we mean by "non-normative".  It 
doesn't mean that you can chop out all the non-normative text and 
still have a complete spec.  It means, rather, that the non-normative
text is being declared, a priori, not to introduce any requirements.  
If it seems to introduce an extra requirement, either there's a defect
(because the normative text is incomplete) or you're interpreting it
wrong.  Normally, if something must be said two ways, we make one 
non-normative to avoid potential conflicts; if a conflict is discovered, 
we've already decided which side wins, and then the editor may fix the 
non-normative bit to more accurately echo the normative bit.

Since defining terms used in the following text doesn't, by itself,
introduce any requirements, it has to be non-normative.  But that
doesn't mean you can pick any random definition for those terms;
the terms really can mean only what the text says.

> >Would anyone object to a committee resolution that the non-normative 
> >word "altered" really was meant to be non-normative, and was not 
> >intended to require extra apparatus in basic_streambuf<>?  We could 
> >go further and remove the word, too, I suppose.
> 
> That would certainly make me more comfortable, but I don't think
> it's enough. The rest of the section, and ideally the rest of the
> standard, should be checked for similar "non-normative" notes to
> make sure they don't actually describe required behavior or that
> they aren't similarly misleading.

I think that process has been going on for a long time.  I think
we have got the "actually describe required behavior" side scrubbed 
fairly well.  What's left is mostly editorial clarification.

This is really about a non-normative note that just has an extra
word that could be interpreted to imply more than the normative 
text requires.  It's a purely editorial job to snip it out.

Nathan Myers
ncm-nospam@cantrip.org