In article <3D880152.3BC7612B@wizard.net>, James Russell Kuyper Jr.
<kuyper@wizard.net> writes
>x_ptr+1 is required to be a valid pointer, legal for use in equality
>comparisons with any other pointer, and legally comparable for order
>with x_ptr itself. However, there's nothing that says that x_ptr[1] has
>to be legal. And I see no reason why x_ptr+1 can't point at the start of
>an entirely different object.

But in protected memory environments, it must point to memory that the
process owns.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> Francis Glassborow wrote:
> ....
> > Now I am
> > also unconvinced that a pointer to one past the end of a single object
> > created with new is required to be a valid pointer. If it were then, for
> > example, on a system that allocates freestore in multiples of 32 chars,
> > with 2-byte (or higher) alignment for structs:
> >
> > struct X {
> >    char data[31];
> > };
> >
> > X * x_ptr = new X;
> >
> > would have to allocate 64 chars just to ensure that x_ptr[1] was a valid
> > address.

kuyper@wizard.net ("James Russell Kuyper Jr.") wrote
> x_ptr+1 is required to be a valid pointer, legal for use in equality
> comparisons with any other pointer, and legally comparable for order
> with x_ptr itself. However, there's nothing that says that x_ptr[1] has
> to be legal. And I see no reason why x_ptr+1 can't point at the start of
> an entirely different object.

I think you're saying the same thing in different ways.

Francis's point was that, if you allocate a 32-byte object, that
does not mean that the next 32 bytes are also allocated.

James's point was that, if you allocate a 32-byte object, you
can still take the address of one object beyond.

These can both be right. In a 32-bit address space, a 32-byte object
could be allocated at any address up to 0xFFFFFFDE. In that case, the
past-the-end pointer would be at 0xFFFFFFFE. Clearly there cannot be
a 32-bit object here, but that doesn't mean that the pointer can't
point here -- so long as you don't try to dereference it.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message news:cd6iz4GD6Yi9EwfL@robinton.demon.co.uk...

> But in protected memory environments, it must point to memory that the
> process owns.

Sure. But still, all the memory-manager has to do is to reserve the last byte of the memory chunk(s) used for the heap memory pool. Then you can allocate anything -- the next byte will always be within that -- legal -- memory area, the address, calculated for the past-end pointer points to a healthy location, and one that works with pointer math.

You're not allowed to use that pointer to anything but storing and comparision, especially not to dereference it, or use to calculate a member-object's address. That would definitely shoot the Moon unless half of the memory is reserved.

struct Big { char a[0xfffe]; char b;};

Suppose our manager uses 64k memory blocks and no header.

Big * pB = new pB; // pB points to a start of block;

pBe = pB+1;  // value is pB+0xffff, last byte of the block

pBe - pB;  pBe - 1 ; pBe == pB; pBe > pB;  // all work

&pBe->b; // the address calculation may fail, or if succeeds, points to illegal place
&pBe->a; // technically succeeds

Were you implying the last two uses of the past-end pointer are not marked as UB in the standard?

Paul

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
>
> In article <3D880152.3BC7612B@wizard.net>, James Russell Kuyper Jr.
> <kuyper@wizard.net> writes
> >x_ptr+1 is required to be a valid pointer, legal for use in equality
> >comparisons with any other pointer, and legally comparable for order
> >with x_ptr itself. However, there's nothing that says that x_ptr[1] has
> >to be legal. And I see no reason why x_ptr+1 can't point at the start of
> >an entirely different object.
>
> But in protected memory environments, it must point to memory that the
> process owns.

So you lose one 32-byte allocation chunk per memory-protection block.
That doesn't sound too bad to me. Or are you talking about a system that
creates a seperate memory-protection block for each allocation?

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

vAbazarov@dAnai.com ("Victor Bazarov") wrote (abridged):
> Along those lines, we just had a short exchange of opinions in
> comp.lang.c++ about the necessity of "delete[]" for an array
> allocated by new[].  The fact that size is not required hints
> that the size is kept somewhere.  If the size is kept, why is
> not the fact that the pointer is actually a pointer to an array,
> which would make it possible to allow deallocation using straight
> "delete" (no brackets)?  Is there a reason to require brackets?

The size is only kept for arrays, not for non-arrays. With a non-array
there is no way to tell that it /is/ a non-array.

However, there is often a second count, the size of the object/array in
bytes, as well as the number of objects in the array. Perhaps you are
confusing the second count with the first? Given:

    struct Object { ~Object(); int x; };
    Object *p = new Object;

the run-time may know that p points to a region sizeof(Object) bytes long,
but is not required to deduce that it holds exactly one Object. This is
because the memory manager is permitted to round up block sizes to some
multiple, eg 12 bytes. So if sizeof(Object) is 4 and block size is 12, the
memory manager cannot decide whether p has 0, 1, 2 or 3 objects.

Interestingly, the deduction in the other direction would often be sound.
In other words, if you know sizeof(Object) and the number of objects in
the array, you can often deduce the total size of the block which stores
them, including rounding. The sad thing is the C++ standard does not make
this information available to the global operator delete[](). The lack of
communication between layers of memory management leads to wasted memory
due to storing counts twice. In my view this is a design error.

This is irrelevant as far as your main question is concerned. The number
of elements still has to be stored somewhere. For non-arrays, we know the
count is always 1 so it would be wasteful to store it. Even to store a
1-bit flag to say whether the length was stored would be too much overhead
for some people.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3d867cc6$0$10634$4c41069e@reader1.ash.ops.us.uu.net>, P.J.
Plauger <pjp@dinkumware.com> writes
>Every object in C (and hence in C++) can be treated as an array
>with one element. One past the end pointers are defined for all
>objects.

However we must be careful to understand all the implications. delete[]
can only be applied to pointers resulting from using new[]. Now I am
also unconvinced that a pointer to one past the end of a single object
created with new is required to be a valid pointer. If it were then, for
example, on a system that allocates freestore in multiples of 32 chars,
with 2-byte (or higher) alignment for structs:


struct X {
   char data[31];
};

X * x_ptr = new X;

would have to allocate 64 chars just to ensure that x_ptr[1] was a valid
address.

Perhaps the standard does require that but it seems very wasteful to me.




--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <8c8b368d.0209170445.74875795@posting.google.com>, Randy
Maddox <rmaddox@isicns.com> writes
>According to subclause 2.5.1.1 [lib.alg.foreach] this should be just
>fine.  The description of for_each explicitly states that it "Applies
>f to the result of dereferencing every iterator in the *OPEN* range
>[first, last), starting from first and proceeding to last - 1."  Where
>I added *OPEN* for emphasis that last is NOT included.

Technically it is a half open range.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Victor Bazarov wrote:
 > If the size is kept

The size is kept for some arrays, but not necessarily for
non-arrays. Allowing plain delete for arrays would impose
this size-keeping overhead on all allocated objects.

In practice, many compilers keep sizes for arrays if the
elements need to be destructed. You can write a function
to probe for this (untested):

struct array_probe { };
void *operator new[](const array_probe &, size_t n) { throw n; }
template<typename T>
size_t overhead()
{
     try { new (array_probe()) T[1]; }
     catch (size_t n) { return n - sizeof(T); }
}

Behavior of this code is not actually guaranteed by the
Standard, but in practice, I believe it will work.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> Now I am
> also unconvinced that a pointer to one past the end of a single object
> created with new is required to be a valid pointer. If it were then, for
> example, on a system that allocates freestore in multiples of 32 chars,
> with 2-byte (or higher) alignment for structs:
>
>
> struct X {
>    char data[31];
> };
>
> X * x_ptr = new X;
>
> would have to allocate 64 chars just to ensure that x_ptr[1] was a valid
> address.

By excluding the last 32-byte chunk of the address-space, in the dynamic
storage range, would remove that problem.

Bo-Staffan


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
....
> can only be applied to pointers resulting from using new[]. Now I am
> also unconvinced that a pointer to one past the end of a single object
> created with new is required to be a valid pointer. If it were then, for
> example, on a system that allocates freestore in multiples of 32 chars,
> with 2-byte (or higher) alignment for structs:
>
> struct X {
>    char data[31];
> };
>
> X * x_ptr = new X;
>
> would have to allocate 64 chars just to ensure that x_ptr[1] was a valid
> address.

x_ptr+1 is required to be a valid pointer, legal for use in equality
comparisons with any other pointer, and legally comparable for order
with x_ptr itself. However, there's nothing that says that x_ptr[1] has
to be legal. And I see no reason why x_ptr+1 can't point at the start of
an entirely different object.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hello,

Is this

    void foo(char c)
    {
        // do something with 'c'
    }

    #include <algorithm>
    void bar(const char *s, int n)
    {
        std::for_each(s, s+n, foo);
    }

    int main()
    {
        char A = 'A';
        bar(&A, 1);
    }

fine or should undefined behaviour be expected?  To explain: the
concept of "one past the end of an array" allows us to use many
Standard Library algorithms with regular arrays because pointers
have similar to iterators semantics (forgive my wording if it's
not perfectly correct).  In the code given there is no array
declared/defined.  Can we say with certainty that the Standard
allows to use the address "one past the 'end'" in such case or
would it be a violation?

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

I wrote...
> Hello,
>
> Is this [...]
>


Got an answer in another newsgroup.  Sorry to waste your time
on that issue (the explicit permission to treat a single object
as an array of one is given in 5.7/4).

Along those lines, we just had a short exchange of opinions in
comp.lang.c++ about the necessity of "delete[]" for an array
allocated by new[].  The fact that size is not required hints
that the size is kept somewhere.  If the size is kept, why is
not the fact that the pointer is actually a pointer to an array,
which would make it possible to allow deallocation using straight
"delete" (no brackets)?  Is there a reason to require brackets?

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message news:uoc745jg9i1ffe@corp.supernews.com...

> Is this
>
>     void foo(char c)
>     {
>         // do something with 'c'
>     }
>
>     #include <algorithm>
>     void bar(const char *s, int n)
>     {
>         std::for_each(s, s+n, foo);
>     }
>
>     int main()
>     {
>         char A = 'A';
>         bar(&A, 1);
>     }
>
> fine or should undefined behaviour be expected?  To explain: the
> concept of "one past the end of an array" allows us to use many
> Standard Library algorithms with regular arrays because pointers
> have similar to iterators semantics (forgive my wording if it's
> not perfectly correct).  In the code given there is no array
> declared/defined.  Can we say with certainty that the Standard
> allows to use the address "one past the 'end'" in such case or
> would it be a violation?

Every object in C (and hence in C++) can be treated as an array
with one element. One past the end pointers are defined for all
objects.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Victor Bazarov wrote:
>
> Hello,
>
> Is this
>
>     void foo(char c)
>     {
>         // do something with 'c'
>     }
>
>     #include <algorithm>
>     void bar(const char *s, int n)
>     {
>         std::for_each(s, s+n, foo);
>     }
>
>     int main()
>     {
>         char A = 'A';
>         bar(&A, 1);
>     }
>
> fine or should undefined behaviour be expected?  To explain: the
> concept of "one past the end of an array" allows us to use many
> Standard Library algorithms with regular arrays because pointers
> have similar to iterators semantics (forgive my wording if it's
> not perfectly correct).  In the code given there is no array
> declared/defined.  Can we say with certainty that the Standard
> allows to use the address "one past the 'end'" in such case or
> would it be a violation?

5.7p4: "For the purposes of these operators, a pointer to a nonarray
object behaves the same as a pointer to the first element of an array of
length one with the type of the object as its element type."

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

vAbazarov@dAnai.com ("Victor Bazarov") wrote in message news:<uoc745jg9i1ffe@corp.supernews.com>...

According to subclause 2.5.1.1 [lib.alg.foreach] this should be just
fine.  The description of for_each explicitly states that it "Applies
f to the result of dereferencing every iterator in the *OPEN* range
[first, last), starting from first and proceeding to last - 1."  Where
I added *OPEN* for emphasis that last is NOT included.

In your code snippet below there is no difference between a single
char and an array of 1 character, at least not in terms of applying
for_each, of course new and delete is a different story, but not
relevant here.  Of course, there is the minor difficulty that your
foo() takes a non-const char by value, while bar() takes a pointer to
const char.  And it is also always possible with the type of interface
presented by bar() to get the wrong count, which could lead to
undefined behavior.  But other than that this is OK and should cause
no problem.

Randy.

> Hello,
>
> Is this
>
>     void foo(char c)
>     {
>         // do something with 'c'
>     }
>
>     #include <algorithm>
>     void bar(const char *s, int n)
>     {
>         std::for_each(s, s+n, foo);
>     }
>
>     int main()
>     {
>         char A = 'A';
>         bar(&A, 1);
>     }
>
> fine or should undefined behaviour be expected?  To explain: the
> concept of "one past the end of an array" allows us to use many
> Standard Library algorithms with regular arrays because pointers
> have similar to iterators semantics (forgive my wording if it's
> not perfectly correct).  In the code given there is no array
> declared/defined.  Can we say with certainty that the Standard
> allows to use the address "one past the 'end'" in such case or
> would it be a violation?
>
> Victor
> --
> Please remove capital A's from my address when replying by mail
>
>
> ---
> [ 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.jamesd.demon.co.uk/csc/faq.html                       ]

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Victor>     void bar(const char *s, int n)
Victor>     {
Victor>         std::for_each(s, s+n, foo);
Victor>     }

Victor>     int main()
Victor>     {
Victor>         char A = 'A';
Victor>         bar(&A, 1);
Victor>     }

Victor> fine or should undefined behaviour be expected?

Fine.

Subclause 5.7, paragraph 4:  For the purposes of these operations
[+ and - with a pointer and an integer as operands], a pointer to
a nonarray object behaves the same as a pointer to the first element
of an array of length one with the type of the object as its
element type.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

vAbazarov@dAnai.com ("Victor Bazarov") wrote in message news:<uoc745jg9i1ffe@corp.supernews.com>...
> Hello,
>
> Is this
>
>     void foo(char c);

>     #include <algorithm>
>     void bar(const char *s, int n)
>     {
>         std::for_each(s, s+n, foo);
>     }
>     int main()
>     {
>         char A = 'A';
>         bar(&A, 1);
>     }
> fine or should undefined behaviour be expected?  To explain: the
> concept of "one past the end of an array" allows us to use many
> Standard Library algorithms with regular arrays because pointers
> have similar to iterators semantics (forgive my wording if it's
> not perfectly correct).  In the code given there is no array
> declared/defined.  Can we say with certainty that the Standard
> allows to use the address "one past the 'end'" in such case or
> would it be a violation?

5.7 covers this: "For the purposes of these operators, (+ and -, MS)
a pointer to a nonarray object behaves the same as a pointer to the
first element of an array of length one with the type of the object
as its element type". This means (&A)+1 is interpreted according to
the following paragraph:
"...Moreover, if the expression P points to the last element of an
array object, the expression (P)+1 points one past the last element
of the array object ... If both the pointer operand and the result
point to elements of the same array object, or one past the last
element of the array object, the evaluation shall not produce an
overflow...".
Similar wording covers the test for (&A)+1==(&A)+1, which
terminates the for_each loop.

HTH,
--
Michiel Salters

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:uoc745jg9i1ffe@corp.supernews.com...
> To explain: the
> concept of "one past the end of an array" allows us to use many
> Standard Library algorithms with regular arrays because pointers
> have similar to iterators semantics (forgive my wording if it's
> not perfectly correct).  In the code given there is no array
> declared/defined.  Can we say with certainty that the Standard
> allows to use the address "one past the 'end'" in such case or
> would it be a violation?

5.7 Additive operators
4. For the purposes of these operators, a pointer to a nonarray object
behaves the same as a pointer to the first element of an array of length
one with the type of the object as its element type.

With other words, you should be able to do ptr_to_non_array + 1.

--
Dag Henriksson


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 16 Sep 2002 22:31:11 +0000 (UTC), vAbazarov@dAnai.com ("Victor
Bazarov") wrote:

[...]
>To explain: the
>concept of "one past the end of an array" allows us to use many
>Standard Library algorithms with regular arrays because pointers
>have similar to iterators semantics (forgive my wording if it's
>not perfectly correct).  In the code given there is no array
>declared/defined.  Can we say with certainty that the Standard
>allows to use the address "one past the 'end'" in such case or
>would it be a violation?

Part of the answer is in 5.7/4

Genny.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]