From 3309963025583600154 X-Google-Thread: 7894ca11fe,e2347147b98ac8c4 X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news1.google.com!news.glorb.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: =?ISO-8859-1?Q?Joaqu=EDn_M_L=F3pez_Mu=F1oz?= Newsgroups: comp.std.c++ Subject: Re: Adding 0 to the null pointer Date: Wed, 27 May 2009 10:37:33 CST Organization: http://groups.google.com Lines: 84 Sender: cppmods@cs.rpi.edu Approved: stephen.clamage@sun.com Message-ID: <071f0de8-b1b2-41e0-af92-a927388f0289@g20g2000vba.googlegroups.com> References: <7c71cedf-287b-4fed-a4b0-807160d2e59e@g1g2000yqh.googlegroups.com> NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; charset=windows-1252 To: (Usenet) Return-Path: X-Original-Date: Wed, 27 May 2009 02:39:30 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:740 On 27 mayo, 00:47, daniel.krueg...@googlemail.com wrote: > On 26 Mai, 18:37, Joaquín M López Muñoz wrote: > > > The (C++03) standard does not say whether result in > > std::copy(first,last,result) must be a valid pointer, > > I don't agree with this general statement. An invalid > pointer may have different reasons. If e.g. the third > argument of std::copy in your example above would > be /indeterminate/, it would not be copyable and > this could legally be checked by any implementation > where the OS supports this kind of detection. > > In regard to a null pointer value this problem does not > exist in *exactly* the same way. But the gray-zone > argument that may hit you here is the term /singular/ > pointer value. As of 24.2 [iterator.concepts]/6 (N2857): > > "[..] Iterators can also have singular values that are > not associated with any container. [ Example: After > the declaration of an uninitialized pointer x (as with > int* x;), x must always be assumed to have a singular > value of a pointer. —end example ] Results of most > expressions are undefined for singular values; the > only exceptions are destroying an iterator that holds > a singular value and the assignment of a non-singular > value to an iterator that holds a singular value. In > this case the singular value is overwritten the same > way as any other value.[..]" > > I think for some reasonable definition of "container" > we both agree that a null pointer value does not have > an associated container. So, if the algorithm may > use a single operation except for a writing assignment > using an non-singular value or destruction your are lost ;-) > > Funnily we have a single type of operation here from > all Output iterator operations that std::copy may use > without violating the spec and this is either copy- > constructing or copy-assigning the value. By the exact > wording of the currently written standard, you are > running into undefined behavior here, even though, when > we look from a different angle (e.g. from the position > that the output iterator actually was a built-in pointer > and that we can copy a null pointer value at our will), the > operation would be well-defined. > OK, so your stance is that null pointers are singular. I don't think so: null pointers can be passed around, copied, tested for equality, etc., none of which operations are allowed for singular values. The whole null->singular issue is a little murky and badly dealt with in the standard text. Resolution of issue 208: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208 replaces the statement Dereferenceable and past-the-end values are always non-singular. with the laxer Dereferenceable values are always non-singular. so as to allow null pointers to serve as past-the-end iterators. It even explicit states in the rationale "Null pointers are singular". The problem with that is that singular iterators cannot be moved around or tested for equality, which is clearly required from past-the-end iterators. I smell a DR here. Your opinions on this are much appreciated, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]