Am 11.09.2011 18:12, schrieb Kazutoshi Satoda:
[..]
>>
>> It
>> is true, that the reader must somehow understand that the "capacity"
>> mentioned in p2 must refer to the more indirect requirement expressed by
>> "storage sufficient to store up to n adjacent T objects".
>
> How a reader can understand such relation on the original wording? I
> think some external information (like the quote from TC++PL) is required
> to conclude as such.

Let me first point out that from your original posting and your
replies to my questions it did not really become clear what your
actual criticism of the wording was. You suggested a replacement but
you did not explain *why* you suggested these changes and I understood
you (incorrectly) that you were suggestion purely editorial changes.
And the suggestions made so far did not really say something very
different from what the normative wording says. I think I can agree
with you that the current wording does not *really* make clear whether
buffer returns with less (or more) of the requested capacity are
conforming or not. I also believe that this is probably not editorial
and an LWG issue should be opened for this.

Thanks & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Martin Bonner wrote:
>>
>> I read this as prohibiting to return a buffer of which capacity is less
>> than n, because such a buffer is not sufficient to store n objects.
>
> Correct.  What other reading is possible?
>
>> Now I propose the following wordings.
>
> Sorry, you haven't explained what is wrong with the current wording.

My above reading, and your reading, render many existing
implementations (which can return a buffer of which capacity is less
than n) non-conforming.
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_tempbuf.h?revision=169421&view=markup#l67

--
k_satoda


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Daniel Kr   gler wrote:
>
> If at all this looks more like an editorial problem to me, no real
> defect in the wording.

What is the difference of "editorial problem" and "real defect" ?

AFAIK, all problem reports about standard are collectively treated
"Defect Report". Thus I believe this problem (unclear wording) is a
defect.
http://www.comeaucomputing.com/csc/faq.html#B13

If I should report "editorial problem" in other way, please explain what
is it and how to report it.

> I also believe that the suggested form "having
> up to n capacity" is bad English.

Sorry but, I'm not a native English speaker and I'm not sure how bad the
wording was.

However, here is another try. I hope the editors in standard committee
will give better wording if it is still bad. Complete ignorance of my
wording is also OK for me if the original intent was clarified in the
standard.

Proposed resolution:

Change 20.6.11 [temporary.buffer] paragraph 1 and 2 to

Effects: Obtains a pointer to storage whose capacity (number of
adjacent T objects storable in it) is up to n. It is implementation
defined whether over-aligned types are supported (3.11).

Returns: A pair containing the buffer's address and capacity (in the
units of sizeof(T)), or a pair of 0 values if no storage can be
obtained or if n <= 0.

--
k_satoda


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 28.08.2011 17:41, schrieb Kazutoshi Satoda:
>  Daniel Kr   gler wrote:
>>
>>  If at all this looks more like an editorial problem to me, no real
>>  defect in the wording.
>
>  What is the difference of "editorial problem" and "real defect" ?

A "real defect" demonstrates that there is a clear contradiction in the
wording or that the wording clearly says something that could not be
(reasonably) intended. As of your current explanations I could not find
any evidence for this matter.

>  AFAIK, all problem reports about standard are collectively treated
>  "Defect Report". Thus I believe this problem (unclear wording) is a
>  defect.
>  http://www.comeaucomputing.com/csc/faq.html#B13
>
>  If I should report "editorial problem" in other way, please explain what
>  is it and how to report it.

I'm still missing your rationale. As of you have written so far, I
couldn't find evidence for this.

>>  I also believe that the suggested form "having
>>  up to n capacity" is bad English.
>
>  Sorry but, I'm not a native English speaker and I'm not sure how bad the
>  wording was.
>
>  However, here is another try. I hope the editors in standard committee
>  will give better wording if it is still bad. Complete ignorance of my
>  wording is also OK for me if the original intent was clarified in the
>  standard.
>
>  Proposed resolution:
>
>  Change 20.6.11 [temporary.buffer] paragraph 1 and 2 to
>
>  Effects: Obtains a pointer to storage whose capacity (number of
>  adjacent T objects storable in it) is up to n. It is implementation
>  defined whether over-aligned types are supported (3.11).
>
>  Returns: A pair containing the buffer's address and capacity (in the
>  units of sizeof(T)), or a pair of 0 values if no storage can be
>  obtained or if n<= 0.

Yes, this wording suggestion would make the wording state clearer. But I
still do not see how the current wording says something differently. It
is true, that the reader must somehow understand that the "capacity"
mentioned in p2 must refer to the more indirect requirement expressed by
"storage sufficient to store up to n adjacent T objects". Could you
please provide a more elaborate description how the current wording
state could be misinterpreted? If there exist a real-world example of
this misinterpretation, this would be even better.

Greetings from Bremen,

Daniel Kr  gler




--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Daniel Kr  gler wrote:
>  Could you
>  please provide a more elaborate description how the current wording
>  state could be misinterpreted? If there exist a real-world example of
>  this misinterpretation, this would be even better.

There seems to be two different targets of the "up to n" modification:
The capacity of obtained buffer, and the actual number that the caller
will store into the buffer.

First I read as the latter, and got surprised seeing that libstdc++
implementation can return a smaller buffer. I started searching about
get_temporary_buffer(). After reading a quote from TC++PL at
stackoverflow, I realized that the former is intended.
http://stackoverflow.com/questions/3264299/why-do-i-need-stdget-temporary-buffer

Such misinterpretation seems common:
   - The above question is likely started from same misinterpretation.
   - JIS standard (Japanese translation of ISO/IEC standard) says nothing
     like "up to". I think the editor misinterpreted the original wording,
     and omitted words for "up to" as it is redundant. (If a buffer is
     sufficient to store n objects, it is also sufficient to store
     up to n objects.)
   - Rogue Wave implementation doesn't return smaller buffer, instead, it
     can return larger buffer on some circumstances.
     Apache STDCXX http://stdcxx.apache.org/ is a derived version of that
     implementation, and publicly accessible.
     http://svn.apache.org/viewvc/stdcxx/trunk/include/rw/_rawiter.h?view=markup&pathrev=1162883#l123
     http://svn.apache.org/viewvc/stdcxx/trunk/src/tmpbuf.cpp?view=markup&pathrev=1162883#l55
     http://stdcxx.apache.org/doc/stdlibref/get-temporary-buffer.html
     >  Specializations of the get_temporary_buffer() function template
     >  attempt to allocate a region of storage sufficiently large to store at
     >  least n adjacent objects of type T.
     I know one commercial compiler package based on Rogue Wave
     implementation, and its implementation is essentially same as the
     above.

>  It
>  is true, that the reader must somehow understand that the "capacity"
>  mentioned in p2 must refer to the more indirect requirement expressed by
>  "storage sufficient to store up to n adjacent T objects".

How a reader can understand such relation on the original wording? I
think some external information (like the quote from TC++PL) is required
to conclude as such.

--
k_satoda


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]