>    22.2.1.4.2/13 prevents codecvt::length() from ever getting itself
> into such a bind: that is, the state of having advanced its current
> location so far from its starting location, that the distance between
> the two locations exceeds the maximum value that its return type can
> represent.

   I cannot find 22.2.1.4.2. I have only 22.2.1.4 as "22.2.1.4 Class
ctype_byname<char>". Which point of standard did you mean? Can you
paste here the appropriate part because I don't understand you replay
now at all...

   Adam Badura


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

Uzytkownik "Greg Herlihy" <greghe@pacbell.net> napisal w wiadomosci
news:1159348327.426135.120060@h48g2000cwc.googlegroups.com...
>
> abadura wrote:
>>    So OK. From 9a (and constraints on codecvt::do_in) it is quite clear
>> that "max" must such a value that "to+max" and "(to+max)-to" are valid
>> and well-defined. And since "(to+max)-to"="max" but is of type
>> "ptrdiff_t" (because it is arithemtic on pointers). So "max" can be
>> represented by an object of "ptrdiff_t" type.
>>    Now we now that the result comes from "max" (so can be stored in
>> "ptrdiff_t") or from "from_end-from" (again "ptrdiff_t") or is less
>> then "from_end-from" (because of the coding properties (again can be
>> sotred in "ptrdiff_t").
>>    But the return value is of type "int" not "ptrdiff_t". And note that
>> preconditions do not mention that "from_end-from" must fit into "int".
>>
>>    So now suppose that "int" has 32 bits, "ptrdiff_t" has 64 bits (must
>> be signed) and "size_t" has also 64 bits (i suppose it must be
>> unsigned). As for my knowledge this is possible for an implementation.
>> If you think that not then please point parts of standard that forbid
>> this (I couldn't find them).
>>    Now it is possible to give such (valid) values for as arguments that
>> the specified result will not fit into "int". What then?
>
>    22.2.1.4.2/13 prevents codecvt::length() from ever getting itself
> into such a bind: that is, the state of having advanced its current
> location so far from its starting location, that the distance between
> the two locations exceeds the maximum value that its return type can
> represent.
>
> Instead we can deduce that as soon as the distance between
> codecvt::length()'s starting and current location becomes equal to the
> maximum value that length() can return for its result - the method
> stops advancing and returns MAX_INT as the result.
>

Where did you get that "state of being advanced" and "MAX_INT" of yours?
Neither is mentioned by    22.2.1.4.2/13.  On the other hand, the paragraph
says that it returns std::min<size_t>(size_t, ptrdiff_t).  There is no way
to make it into an int in a reliable way and it is a defect; it is not the
only one of this sort (cf. DR 255, although this one is much more critical
because there is no workaround).  I hope the whole STL interface is going to
be revised wrt ptrdiff_t consistency and fixed ASAP.

Chris



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

Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
news:1159376160.335638.70630@i3g2000cwc.googlegroups.com...
>>    22.2.1.4.2/13 prevents codecvt::length() from ever getting itself
>> into such a bind: that is, the state of having advanced its current
>> location so far from its starting location, that the distance between
>> the two locations exceeds the maximum value that its return type can
>> represent.
>
>   I cannot find 22.2.1.4.2. I have only 22.2.1.4 as "22.2.1.4 Class
> ctype_byname<char>". Which point of standard did you mean? Can you
> paste here the appropriate part because I don't understand you replay
> now at all...
>
[lib.locale.codecvt.virtuals], although I still can see no similar
restriction there.

Chris



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

Kristof Zelechovski wrote:
> Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
> news:1159376160.335638.70630@i3g2000cwc.googlegroups.com...
> >>    22.2.1.4.2/13 prevents codecvt::length() from ever getting itself
> >> into such a bind: that is, the state of having advanced its current
> >> location so far from its starting location, that the distance between
> >> the two locations exceeds the maximum value that its return type can
> >> represent.
> >
> >   I cannot find 22.2.1.4.2. I have only 22.2.1.4 as "22.2.1.4 Class
> > ctype_byname<char>". Which point of standard did you mean? Can you
> > paste here the appropriate part because I don't understand you replay
> > now at all...
> >
> [lib.locale.codecvt.virtuals], although I still can see no similar
> restriction there.

In my copy, that section is numbered 22.2.1.5.2, and does not have a
paragraph 13. The fact that do_max_length() returns an 'int' value,
combined with the definition given for the meaning of do_max_length()'s
return value, implies such a retriction. However, I'm not sure that's
the argument that Greg Herlihy was trying (and failing) to imply - it
seems inconsistent with the vague hints he's dropped as to how he
derived his conclusion.


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

kuyper@wizard.net wrote:
> Kristof Zelechovski wrote:
>> Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
>> news:1159376160.335638.70630@i3g2000cwc.googlegroups.com...
>>>> =A722.2.1.4.2/13 prevents codecvt::length() from ever getting itself
>>>> into such a bind: that is, the state of having advanced its current
>>>> location so far from its starting location, that the distance betwee=
n
>>>> the two locations exceeds the maximum value that its return type can
>>>> represent.
>>>   I cannot find 22.2.1.4.2. I have only 22.2.1.4 as "22.2.1.4 Class
>>> ctype_byname<char>". Which point of standard did you mean? Can you
>>> paste here the appropriate part because I don't understand you replay
>>> now at all...
>>>
>> [lib.locale.codecvt.virtuals], although I still can see no similar
>> restriction there.
>=20
> In my copy, that section is numbered 22.2.1.5.2, and does not have a
> paragraph 13.

[lib.locale.codecvt.virtuals] is 22.2.1.5.2 in the 2003 standard. It=20
moved to 22.2.1.4.2 in the current working draft.

In general, references to the working draft should be by the label and=20
not by [sub]section numbers. Those numbers will change as things are=20
added or modified. The labels will stay the same.

Well, almost the same: the initial "lib." is about to go away. That=20
makes it much easier to find things in an alphabetical list that maps=20
labels to section numbers, which will be included in the next revision=20
of the working draft.

--=20

 -- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and=20
Reference." For more information about this book, see=20
www.petebecker.com/tr1book.

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

   Why does codecvt::length make implicit assumptions on standard
typedefs?

   In the Standard we can find [22.2.1.5 Class template codecvt] that
codecvt::length has following declaration:

int length(stateT&, const externT* from, const externT* end, size_t
max) const;

   The result could be the value of "max". But "max" is of type
"size_t" which does not have to be int. I even suppose (but cannot find
it in the Standard right now - can any one help?) that size_t is
unsigned. In fact on one compiler I checked (MS VS.NET 2005)
size_t=unsigned int. So it is possible that length would not be able to
return the true value because it is to big to be stored in int.
   The same is true when the return value should be end-from which is
of type ptrdiff_t.
   Also if the return value is some other function of the arguments it
still could be to big for int.

   Should it have additional "ifs" for checking this case and returning
numeric_limits<int>::max()? The Standard doesn't seem (for me) to
specify this.

   Adam Badura

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

abadura wrote:
> Why does codecvt::length make implicit assumptions on standard
> typedefs?
>
>    In the Standard we can find [22.2.1.5 Class template codecvt] that
> codecvt::length has following declaration:
>
> int length(stateT&, const externT* from, const externT* end, size_t
> max) const;

Probably for the same reason that some people are inclined to jump to
conclusions about the preconditions of a function - based on nothing
more than the types of the parameters it declares. Whereas with a bit
more research, these same individuals would probably discover that
function like codevct::length() makes no assumptions about the size of
any parameter type or anything else for that matter. On the contrary,
the documentation for codecvt::length() routine makes quite clear what
values constitute valid input.

In fact the Standard documents the preconditions for every routine in
the library for which any exist. And codecvt::length() is a case in
point. The Standard's description of codecvt::length() specifies (among
other things) that max's value is not to exceed the extent of the range
that lies between the "from" and "end" parameters. So as it turns out,
a caller is not at liberty to pass any value for max that a size_t type
can hold. Instead a caller must be sure that max's value passed is not
too large, otherwise length() will not treat the value as valid input.

Now there is one question that could be raised here: why declare max as
a size_t type when a smaller type would also be sufficient? The answer
is simply: a function parameter type serves primarily to communicate
the role of that parameter as input to, or as output from, that
function. (In this case, size_t indicates that max's value is a metric
of dimension.) A function parameter type therefore does not necessarily
document the full range of valid input for that parameter. Granted, the
type of a function parameter does place an absolute limit on the range
of possible argument values - but the function itself (often as a
member of a programming interface) can constrain the range of valid
input values further. And it is obviously important for a programmer to
be aware of any such constraints before calling a function that has
them - a function like codecvt::length(), for example.

Greg

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

> Probably for the same reason that some people are inclined to jump to
> conclusions about the preconditions of a function - based on nothing
> more than the types of the parameters it declares. Whereas with a bit
> more research, these same individuals would probably discover that
> function like codevct::length() makes no assumptions about the size of
> any parameter type or anything else for that matter. On the contrary,
> the documentation for codecvt::length() routine makes quite clear what
> values constitute valid input.

   Notice that I did read the Standard (this part of it) so instead of
such words like this you could show the appropriate parts of the
Standard and the "more research" if it is so clear...

> In fact the Standard documents the preconditions for every routine in
> the library for which any exist. And codecvt::length() is a case in
> point. The Standard's description of codecvt::length() specifies (among
> other things) that max's value is not to exceed the extent of the range
> that lies between the "from" and "end" parameters. So as it turns out,
> a caller is not at liberty to pass any value for max that a size_t type
> can hold. Instead a caller must be sure that max's value passed is not
> too large, otherwise length() will not treat the value as valid input.

   The stnadard says [22.2.1.5.2 codecvt virtual functions (9-11)]

----------
int do_length(stateT& state, const externT* from, const externT*
from_end, size_t max) const;

9
Preconditions: (from<=from_end) well-defined and true; state
initialized, if at the beginning of a sequence, or else equal to the
result of converting the preceding characters in the sequence.

9a
Effects: The effect on the state argument is "as if" it called
do_in(state, from, from_end, from, to, to+max, to) for to pointing to a
buffer of at least max elements.

10
Returns: (from_next-from) where from_next is the largest value in the
range [from,from_end] such that the sequence of values in the range
[from,from_next) represents max or fewer valid complete characters of
type internT. The instantiations required in Table 51 (22.1.1.1.1),
namely codecvt<wchar_t, char, mbstate_t> and codecvt<char, char,
mbstate_t>, return the lesser of max and (from_end-from).
----------

   So OK. From 9a (and constraints on codecvt::do_in) it is quite clear
that "max" must such a value that "to+max" and "(to+max)-to" are valid
and well-defined. And since "(to+max)-to"="max" but is of type
"ptrdiff_t" (because it is arithemtic on pointers). So "max" can be
represented by an object of "ptrdiff_t" type.
   Now we now that the result comes from "max" (so can be stored in
"ptrdiff_t") or from "from_end-from" (again "ptrdiff_t") or is less
then "from_end-from" (because of the coding properties (again can be
sotred in "ptrdiff_t").
   But the return value is of type "int" not "ptrdiff_t". And note that
preconditions do not mention that "from_end-from" must fit into "int".

   So now suppose that "int" has 32 bits, "ptrdiff_t" has 64 bits (must
be signed) and "size_t" has also 64 bits (i suppose it must be
unsigned). As for my knowledge this is possible for an implementation.
If you think that not then please point parts of standard that forbid
this (I couldn't find them).
   Now it is possible to give such (valid) values for as arguments that
the specified result will not fit into "int". What then?

   Adam Badura

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

abadura wrote:
>    So OK. From 9a (and constraints on codecvt::do_in) it is quite clear
> that "max" must such a value that "to+max" and "(to+max)-to" are valid
> and well-defined. And since "(to+max)-to"="max" but is of type
> "ptrdiff_t" (because it is arithemtic on pointers). So "max" can be
> represented by an object of "ptrdiff_t" type.
>    Now we now that the result comes from "max" (so can be stored in
> "ptrdiff_t") or from "from_end-from" (again "ptrdiff_t") or is less
> then "from_end-from" (because of the coding properties (again can be
> sotred in "ptrdiff_t").
>    But the return value is of type "int" not "ptrdiff_t". And note that
> preconditions do not mention that "from_end-from" must fit into "int".
>
>    So now suppose that "int" has 32 bits, "ptrdiff_t" has 64 bits (must
> be signed) and "size_t" has also 64 bits (i suppose it must be
> unsigned). As for my knowledge this is possible for an implementation.
> If you think that not then please point parts of standard that forbid
> this (I couldn't find them).
>    Now it is possible to give such (valid) values for as arguments that
> the specified result will not fit into "int". What then?

   22.2.1.4.2/13 prevents codecvt::length() from ever getting itself
into such a bind: that is, the state of having advanced its current
location so far from its starting location, that the distance between
the two locations exceeds the maximum value that its return type can
represent.

Instead we can deduce that as soon as the distance between
codecvt::length()'s starting and current location becomes equal to the
maximum value that length() can return for its result - the method
stops advancing and returns MAX_INT as the result.

Greg


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