Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #6963 > unrolled thread

Strict aliasing and buffer handling

Back to article view | Back to comp.lang.c++

Contents

  Strict aliasing and buffer handling Francois Duranleau <xiao.bai.xiong@gmail.com> - 2011-06-20 09:59 -0700
    Re: Strict aliasing and buffer handling "Paul" <pchristor@yahoo.co.uk> - 2011-06-20 19:39 +0100
      Re: Strict aliasing and buffer handling Francois Duranleau <xiao.bai.xiong@gmail.com> - 2011-06-20 11:56 -0700
        Re: Strict aliasing and buffer handling Leigh Johnston <leigh@i42.co.uk> - 2011-06-20 20:12 +0100
          Re: Strict aliasing and buffer handling Francois Duranleau <xiao.bai.xiong@gmail.com> - 2011-06-20 12:39 -0700
            Re: Strict aliasing and buffer handling Leigh Johnston <leigh@i42.co.uk> - 2011-06-20 20:49 +0100
              Re: Strict aliasing and buffer handling "Paul" <pchristor@yahoo.co.uk> - 2011-06-20 21:12 +0100
                Re: Strict aliasing and buffer handling Leigh Johnston <leigh@i42.co.uk> - 2011-06-20 21:20 +0100
                  Re: Strict aliasing and buffer handling "Paul" <pchristor@yahoo.co.uk> - 2011-06-21 10:35 +0100
                    Re: Strict aliasing and buffer handling Leigh Johnston <leigh@i42.co.uk> - 2011-06-21 12:35 +0100
                      Re: Strict aliasing and buffer handling "Paul" <pchristor@yahoo.co.uk> - 2011-06-21 12:37 +0100
            Re: Strict aliasing and buffer handling "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-20 22:16 +0200
              Re: Strict aliasing and buffer handling Francois Duranleau <xiao.bai.xiong@gmail.com> - 2011-06-20 13:29 -0700
                Re: Strict aliasing and buffer handling "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-20 23:27 +0200
                  Re: Strict aliasing and buffer handling Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-20 14:37 -0700
                    Re: Strict aliasing and buffer handling "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-21 00:31 +0200
                      Re: Strict aliasing and buffer handling Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-20 19:37 -0700
                  Re: Strict aliasing and buffer handling Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-06-20 23:38 +0200
                    Re: Strict aliasing and buffer handling "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-21 00:46 +0200
                      Re: Strict aliasing and buffer handling Francois Duranleau <xiao.bai.xiong@gmail.com> - 2011-06-21 05:03 -0700
                        Re: Strict aliasing and buffer handling "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-21 16:19 +0200
                          Re: Strict aliasing and buffer handling Francois Duranleau <xiao.bai.xiong@gmail.com> - 2011-06-21 09:08 -0700
                            Re: Strict aliasing and buffer handling "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-22 01:43 +0200
    Re: Strict aliasing and buffer handling Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-20 14:49 -0700
    Re: Strict aliasing and buffer handling "io_x" <a@b.c.invalid> - 2011-06-21 09:12 +0200
      Re: Strict aliasing and buffer handling Ian Collins <ian-news@hotmail.com> - 2011-06-21 20:14 +1200

Page 1 of 2  [1] 2  Next page →

#6963 — Strict aliasing and buffer handling

Hi,

I am facing a situation where I would like to follow strict aliasing,
but, unless I misunderstand the standard, I can't find a solution
without sacrificing performance, memory size, etc.

The problem is as follows. Essentially, I have a runtime description
of a buffer's layout in memory. The information is essentially a set
of offset (in bytes) with type of data located at that offset. There
is an API I use that needs the data to be sent in that particular
layout. A common method of dealing with such a buffer is something
like this:

- Buffer is allocated like this:

char* buffer = new char[buffer_size];

- Assigning/querying data from that buffer is done with something like
this:

template < typename T >
void set_buffer_data(char* buffer, unsigned int offset, const T& data)
{
    T* d = reinterpret_cast<T*>(buffer + offset);
    *d = data;
}

template < typename T >
const T& get_buffer_data(const char* buffer, unsigned int offset)
{
    const T* d = reinterpret_cast<const T*>(buffer + offset);
    return *d;
}

I am volontarily simplifying things to better illustrate the problem,
so never mind alignment and type safety problems, and proper
initialization of the buffer's content with non-POD types.

Now, if I read the standard correctly (3.10-15), this is a violation
of strict aliasing because casting from char* to T* (T != char or
unsigned char) and then accessing the data via that pointer is not
allowed. But then, how can we handle this without sacrificing
performance and memory?

We could do memcpy, e.g.

template < typename T >
void set_buffer_data(char* buffer, unsigned int offset, const T& data)
{
    memcpy(buffer + offset, &data, sizeof(T));
}

template < typename T >
void get_buffer_data(const char* buffer, unsigned int offset, T& data)
{
    memcpy(&data, buffer + offset, sizeof(T));
}

and hope the compiler optimizes this well. But then, what about non-
PODs? And get_buffer_data now needs to return a copy all the times (I
could live with that, though, as most of the times, the return value
would be assigned to a non-reference variable anyways).

For the record, a concrete example for this problem is when dealing
with OpenGL's uniform buffers (I guess it would be similar with
D3D10+'s constant buffers). At runtime, you get a layout description
of a buffer, and you have to respect that layout to send the data.

--
Francois Duranleau

[toc] | [next] | [standalone]

#6967

"Francois Duranleau" <xiao.bai.xiong@gmail.com> wrote in message 
news:f70612e6-c4e9-4166-842a-afc158fba36e@k6g2000yqc.googlegroups.com...
> Hi,
>
> I am facing a situation where I would like to follow strict aliasing,
> but, unless I misunderstand the standard, I can't find a solution
> without sacrificing performance, memory size, etc.
>
> The problem is as follows. Essentially, I have a runtime description
> of a buffer's layout in memory. The information is essentially a set
> of offset (in bytes) with type of data located at that offset. There
> is an API I use that needs the data to be sent in that particular
> layout. A common method of dealing with such a buffer is something
> like this:
>
> - Buffer is allocated like this:
>
> char* buffer = new char[buffer_size];
>
> - Assigning/querying data from that buffer is done with something like
> this:
>
> template < typename T >
> void set_buffer_data(char* buffer, unsigned int offset, const T& data)
> {
>    T* d = reinterpret_cast<T*>(buffer + offset);
>    *d = data;
> }
>
> template < typename T >
> const T& get_buffer_data(const char* buffer, unsigned int offset)
> {
>    const T* d = reinterpret_cast<const T*>(buffer + offset);
>    return *d;
> }
>
> I am volontarily simplifying things to better illustrate the problem,
> so never mind alignment and type safety problems, and proper
> initialization of the buffer's content with non-POD types.
>
> Now, if I read the standard correctly (3.10-15), this is a violation
> of strict aliasing because casting from char* to T* (T != char or
> unsigned char) and then accessing the data via that pointer is not
> allowed. But then, how can we handle this without sacrificing
> performance and memory?
>
> We could do memcpy, e.g.
>
> template < typename T >
> void set_buffer_data(char* buffer, unsigned int offset, const T& data)
> {
>    memcpy(buffer + offset, &data, sizeof(T));
> }
>
> template < typename T >
> void get_buffer_data(const char* buffer, unsigned int offset, T& data)
> {
>    memcpy(&data, buffer + offset, sizeof(T));
> }
>
> and hope the compiler optimizes this well. But then, what about non-
> PODs? And get_buffer_data now needs to return a copy all the times (I
> could live with that, though, as most of the times, the return value
> would be assigned to a non-reference variable anyways).
>
> For the record, a concrete example for this problem is when dealing
> with OpenGL's uniform buffers (I guess it would be similar with
> D3D10+'s constant buffers). At runtime, you get a layout description
> of a buffer, and you have to respect that layout to send the data.
>
> --
Have you considered placement new ?
Maybe that is another option for you. 

[toc] | [prev] | [next] | [standalone]

#6968

On Jun 20, 2:39 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> Have you considered placement new ?
> Maybe that is another option for you.

Yes, but it does not solve the strict aliasing issue, because before
assigning, we would need to call the destructor for what was there,
but then we would also need to make a cast to call this destructor,
e.g.

template < typename T >
void set_buffer_value(char* buffer, unsigned int offset, const T&
value)
{
    // line below still violates strict aliasing
    reinterpret_cast<T*>(buffer + offset)->~T();
    new (buffer + offset) T(value);
}

--
Francois Duranleau

[toc] | [prev] | [next] | [standalone]

#6969

On 20/06/2011 19:56, Francois Duranleau wrote:
> On Jun 20, 2:39 pm, "Paul"<pchris...@yahoo.co.uk>  wrote:
>>
>> Have you considered placement new ?
>> Maybe that is another option for you.
>
> Yes, but it does not solve the strict aliasing issue, because before
> assigning, we would need to call the destructor for what was there,
> but then we would also need to make a cast to call this destructor,
> e.g.
>
> template<  typename T>
> void set_buffer_value(char* buffer, unsigned int offset, const T&
> value)
> {
>      // line below still violates strict aliasing
>      reinterpret_cast<T*>(buffer + offset)->~T();
>      new (buffer + offset) T(value);
> }
>

AFAIK char* is an allowable exception to strict aliasing rules.

/Leigh

[toc] | [prev] | [next] | [standalone]

#6971

On Jun 20, 3:12 pm, Leigh Johnston <le...@i42.co.uk> wrote:
>
> AFAIK char* is an allowable exception to strict aliasing rules.

I would like to believe so, but in the standard, it says you can
access the storage of anything via char* or unsigned char*, not the
other way around, which is what bugs me.

There was a discussion about that on Boost developers mailing list
(http://groups.google.com/group/boost-developers-archive/browse_thread/
thread/aa1bd1c1f285f8f8/913ad1a9678ac67e) concerning Boost.Variant
(http://www.boost.org/doc/libs/1_46_1/doc/html/variant.html), which
uses a static char buffer to hold data for various types. A quote from
the thread:

"I thought variant just static_cast<char*> to void* then from void* to
T*.  The char* is for the memory buffer in boost::aligned_storage."

which indeed what it does. However, later in the thread, it is also
questioned how this would actually solve the strict aliasing rule
problem, and then there was no answer, except complaints about the
said rule. I tried to look in the standard for specials cases with
static_cast and char*/unsigned char* and void*, but I found nothing of
interest... well, assuming I understood everything where I looked (no
guaranties :) ). I neither read the cover-to-cover 700+ pages.

So I thought there might be some C++ gurus out here with an answer.

--
Francois Duranleau

[toc] | [prev] | [next] | [standalone]

#6972

On 20/06/2011 20:39, Francois Duranleau wrote:
> On Jun 20, 3:12 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>>
>> AFAIK char* is an allowable exception to strict aliasing rules.
>
> I would like to believe so, but in the standard, it says you can
> access the storage of anything via char* or unsigned char*, not the
> other way around, which is what bugs me.
>
> There was a discussion about that on Boost developers mailing list
> (http://groups.google.com/group/boost-developers-archive/browse_thread/
> thread/aa1bd1c1f285f8f8/913ad1a9678ac67e) concerning Boost.Variant
> (http://www.boost.org/doc/libs/1_46_1/doc/html/variant.html), which
> uses a static char buffer to hold data for various types. A quote from
> the thread:
>
> "I thought variant just static_cast<char*>  to void* then from void* to
> T*.  The char* is for the memory buffer in boost::aligned_storage."
>
> which indeed what it does. However, later in the thread, it is also
> questioned how this would actually solve the strict aliasing rule
> problem, and then there was no answer, except complaints about the
> said rule. I tried to look in the standard for specials cases with
> static_cast and char*/unsigned char* and void*, but I found nothing of
> interest... well, assuming I understood everything where I looked (no
> guaranties :) ). I neither read the cover-to-cover 700+ pages.
>
> So I thought there might be some C++ gurus out here with an answer.

Yeah it bugs me too (I have the same problem with my own variant class, 
my own max-size vector class and my own chunk allocator).

What about std::allocator?  By default it will be creating/destroying 
objects within a char array obtained via new.

/Leigh

[toc] | [prev] | [next] | [standalone]

#6975

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:PZudnSSnxeLSOWLQnZ2dnUVZ8jednZ2d@giganews.com...
> On 20/06/2011 20:39, Francois Duranleau wrote:
>> On Jun 20, 3:12 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>>>
>>> AFAIK char* is an allowable exception to strict aliasing rules.
>>
>> I would like to believe so, but in the standard, it says you can
>> access the storage of anything via char* or unsigned char*, not the
>> other way around, which is what bugs me.
>>
>> There was a discussion about that on Boost developers mailing list
>> (http://groups.google.com/group/boost-developers-archive/browse_thread/
>> thread/aa1bd1c1f285f8f8/913ad1a9678ac67e) concerning Boost.Variant
>> (http://www.boost.org/doc/libs/1_46_1/doc/html/variant.html), which
>> uses a static char buffer to hold data for various types. A quote from
>> the thread:
>>
>> "I thought variant just static_cast<char*>  to void* then from void* to
>> T*.  The char* is for the memory buffer in boost::aligned_storage."
>>
>> which indeed what it does. However, later in the thread, it is also
>> questioned how this would actually solve the strict aliasing rule
>> problem, and then there was no answer, except complaints about the
>> said rule. I tried to look in the standard for specials cases with
>> static_cast and char*/unsigned char* and void*, but I found nothing of
>> interest... well, assuming I understood everything where I looked (no
>> guaranties :) ). I neither read the cover-to-cover 700+ pages.
>>
>> So I thought there might be some C++ gurus out here with an answer.
>
> Yeah it bugs me too (I have the same problem with my own variant class, my 
> own max-size vector class and my own chunk allocator).
>
> What about std::allocator?  By default it will be creating/destroying 
> objects within a char array obtained via new.
>
Applying your theory , the char* is pointing to only the first byte, 
therefore the rest of the memory is free to be pointed to by anything, no?
:-) lol

[toc] | [prev] | [next] | [standalone]

#6976

On 20/06/2011 21:12, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:PZudnSSnxeLSOWLQnZ2dnUVZ8jednZ2d@giganews.com...
>> On 20/06/2011 20:39, Francois Duranleau wrote:
>>> On Jun 20, 3:12 pm, Leigh Johnston<le...@i42.co.uk> wrote:
>>>>
>>>> AFAIK char* is an allowable exception to strict aliasing rules.
>>>
>>> I would like to believe so, but in the standard, it says you can
>>> access the storage of anything via char* or unsigned char*, not the
>>> other way around, which is what bugs me.
>>>
>>> There was a discussion about that on Boost developers mailing list
>>> (http://groups.google.com/group/boost-developers-archive/browse_thread/
>>> thread/aa1bd1c1f285f8f8/913ad1a9678ac67e) concerning Boost.Variant
>>> (http://www.boost.org/doc/libs/1_46_1/doc/html/variant.html), which
>>> uses a static char buffer to hold data for various types. A quote from
>>> the thread:
>>>
>>> "I thought variant just static_cast<char*> to void* then from void* to
>>> T*. The char* is for the memory buffer in boost::aligned_storage."
>>>
>>> which indeed what it does. However, later in the thread, it is also
>>> questioned how this would actually solve the strict aliasing rule
>>> problem, and then there was no answer, except complaints about the
>>> said rule. I tried to look in the standard for specials cases with
>>> static_cast and char*/unsigned char* and void*, but I found nothing of
>>> interest... well, assuming I understood everything where I looked (no
>>> guaranties :) ). I neither read the cover-to-cover 700+ pages.
>>>
>>> So I thought there might be some C++ gurus out here with an answer.
>>
>> Yeah it bugs me too (I have the same problem with my own variant
>> class, my own max-size vector class and my own chunk allocator).
>>
>> What about std::allocator? By default it will be creating/destroying
>> objects within a char array obtained via new.
>>
> Applying your theory , the char* is pointing to only the first byte,
> therefore the rest of the memory is free to be pointed to by anything, no?
> :-) lol

You think you are being funny and/or clever but the only thing that is 
laughable is your technical competence.  Get a life and stop trolling here.

/Leigh

[toc] | [prev] | [next] | [standalone]

#6995

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:y5CdneCZfO03NmLQnZ2dnUVZ7oidnZ2d@giganews.com...
>>>>> AFAIK char* is an allowable exception to strict aliasing rules.
>>>>
>>>> I would like to believe so, but in the standard, it says you can
>>>> access the storage of anything via char* or unsigned char*, not the
>>>> other way around, which is what bugs me.
>>>>
>>>> There was a discussion about that on Boost developers mailing list
>>>> (http://groups.google.com/group/boost-developers-archive/browse_thread/
>>>> thread/aa1bd1c1f285f8f8/913ad1a9678ac67e) concerning Boost.Variant
>>>> (http://www.boost.org/doc/libs/1_46_1/doc/html/variant.html), which
>>>> uses a static char buffer to hold data for various types. A quote from
>>>> the thread:
>>>>
>>>> "I thought variant just static_cast<char*> to void* then from void* to
>>>> T*. The char* is for the memory buffer in boost::aligned_storage."
>>>>
>>>> which indeed what it does. However, later in the thread, it is also
>>>> questioned how this would actually solve the strict aliasing rule
>>>> problem, and then there was no answer, except complaints about the
>>>> said rule. I tried to look in the standard for specials cases with
>>>> static_cast and char*/unsigned char* and void*, but I found nothing of
>>>> interest... well, assuming I understood everything where I looked (no
>>>> guaranties :) ). I neither read the cover-to-cover 700+ pages.
>>>>
>>>> So I thought there might be some C++ gurus out here with an answer.
>>>
>>> Yeah it bugs me too (I have the same problem with my own variant
>>> class, my own max-size vector class and my own chunk allocator).
>>>
>>> What about std::allocator? By default it will be creating/destroying
>>> objects within a char array obtained via new.
>>>
>> Applying your theory , the char* is pointing to only the first byte,
>> therefore the rest of the memory is free to be pointed to by anything, 
>> no?
>> :-) lol
>
> You think you are being funny and/or clever but the only thing that is 
> laughable is your technical competence.  Get a life and stop trolling 
> here.
>
But according to you with :
char* p = new char[100];
p only points to the first char. There are 99 unpointed-to chars.


There is nothing wrong with being incorrect now and then but you refuse to 
accept your errors.
So I don't think I am being funny , I actually think you are funny. :-)

[toc] | [prev] | [next] | [standalone]

#7000

On 21/06/2011 10:35, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:y5CdneCZfO03NmLQnZ2dnUVZ7oidnZ2d@giganews.com...
>>>>>> AFAIK char* is an allowable exception to strict aliasing rules.
>>>>>
>>>>> I would like to believe so, but in the standard, it says you can
>>>>> access the storage of anything via char* or unsigned char*, not the
>>>>> other way around, which is what bugs me.
>>>>>
>>>>> There was a discussion about that on Boost developers mailing list
>>>>> (http://groups.google.com/group/boost-developers-archive/browse_thread/
>>>>>
>>>>> thread/aa1bd1c1f285f8f8/913ad1a9678ac67e) concerning Boost.Variant
>>>>> (http://www.boost.org/doc/libs/1_46_1/doc/html/variant.html), which
>>>>> uses a static char buffer to hold data for various types. A quote from
>>>>> the thread:
>>>>>
>>>>> "I thought variant just static_cast<char*> to void* then from void* to
>>>>> T*. The char* is for the memory buffer in boost::aligned_storage."
>>>>>
>>>>> which indeed what it does. However, later in the thread, it is also
>>>>> questioned how this would actually solve the strict aliasing rule
>>>>> problem, and then there was no answer, except complaints about the
>>>>> said rule. I tried to look in the standard for specials cases with
>>>>> static_cast and char*/unsigned char* and void*, but I found nothing of
>>>>> interest... well, assuming I understood everything where I looked (no
>>>>> guaranties :) ). I neither read the cover-to-cover 700+ pages.
>>>>>
>>>>> So I thought there might be some C++ gurus out here with an answer.
>>>>
>>>> Yeah it bugs me too (I have the same problem with my own variant
>>>> class, my own max-size vector class and my own chunk allocator).
>>>>
>>>> What about std::allocator? By default it will be creating/destroying
>>>> objects within a char array obtained via new.
>>>>
>>> Applying your theory , the char* is pointing to only the first byte,
>>> therefore the rest of the memory is free to be pointed to by
>>> anything, no?
>>> :-) lol
>>
>> You think you are being funny and/or clever but the only thing that is
>> laughable is your technical competence. Get a life and stop trolling
>> here.
>>
> But according to you with :
> char* p = new char[100];
> p only points to the first char. There are 99 unpointed-to chars.

Correct, p points the the first element of the array; it does not point 
to the second, third, fourth or any other other element of the array. 
Read the standard about what new[] actually returns.

>
>
> There is nothing wrong with being incorrect now and then but you refuse
> to accept your errors.

What am I incorrect about exactly?

> So I don't think I am being funny , I actually think you are funny. :-)

That is because you don't have the slightest iota of a clue.

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#7001

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:y7adnVQjzvyGH53TnZ2dnUVZ8lCdnZ2d@giganews.com...
> On 21/06/2011 10:35, Paul wrote:
>>
>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>> news:y5CdneCZfO03NmLQnZ2dnUVZ7oidnZ2d@giganews.com...
>>>>>>> AFAIK char* is an allowable exception to strict aliasing rules.
>>>>>>
>>>>>> I would like to believe so, but in the standard, it says you can
>>>>>> access the storage of anything via char* or unsigned char*, not the
>>>>>> other way around, which is what bugs me.
>>>>>>
>>>>>> There was a discussion about that on Boost developers mailing list
>>>>>> (http://groups.google.com/group/boost-developers-archive/browse_thread/
>>>>>>
>>>>>> thread/aa1bd1c1f285f8f8/913ad1a9678ac67e) concerning Boost.Variant
>>>>>> (http://www.boost.org/doc/libs/1_46_1/doc/html/variant.html), which
>>>>>> uses a static char buffer to hold data for various types. A quote 
>>>>>> from
>>>>>> the thread:
>>>>>>
>>>>>> "I thought variant just static_cast<char*> to void* then from void* 
>>>>>> to
>>>>>> T*. The char* is for the memory buffer in boost::aligned_storage."
>>>>>>
>>>>>> which indeed what it does. However, later in the thread, it is also
>>>>>> questioned how this would actually solve the strict aliasing rule
>>>>>> problem, and then there was no answer, except complaints about the
>>>>>> said rule. I tried to look in the standard for specials cases with
>>>>>> static_cast and char*/unsigned char* and void*, but I found nothing 
>>>>>> of
>>>>>> interest... well, assuming I understood everything where I looked (no
>>>>>> guaranties :) ). I neither read the cover-to-cover 700+ pages.
>>>>>>
>>>>>> So I thought there might be some C++ gurus out here with an answer.
>>>>>
>>>>> Yeah it bugs me too (I have the same problem with my own variant
>>>>> class, my own max-size vector class and my own chunk allocator).
>>>>>
>>>>> What about std::allocator? By default it will be creating/destroying
>>>>> objects within a char array obtained via new.
>>>>>
>>>> Applying your theory , the char* is pointing to only the first byte,
>>>> therefore the rest of the memory is free to be pointed to by
>>>> anything, no?
>>>> :-) lol
>>>
>>> You think you are being funny and/or clever but the only thing that is
>>> laughable is your technical competence. Get a life and stop trolling
>>> here.
>>>
>> But according to you with :
>> char* p = new char[100];
>> p only points to the first char. There are 99 unpointed-to chars.
>
> Correct, p points the the first element of the array; it does not point to 
> the second, third, fourth or any other other element of the array. Read 
> the standard about what new[] actually returns.
>
It amazes me how you manage to be so irritating yet amusing at the same 
time. LOL. 

[toc] | [prev] | [next] | [standalone]

#6974

* Francois Duranleau, on 20.06.2011 21:39:
> On Jun 20, 3:12 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>>
>> AFAIK char* is an allowable exception to strict aliasing rules.
>
> I would like to believe so, but in the standard, it says you can
> access the storage of anything via char* or unsigned char*, not the
> other way around, which is what bugs me.
>
> There was a discussion about that on Boost developers mailing list
> (http://groups.google.com/group/boost-developers-archive/browse_thread/
> thread/aa1bd1c1f285f8f8/913ad1a9678ac67e) concerning Boost.Variant
> (http://www.boost.org/doc/libs/1_46_1/doc/html/variant.html), which
> uses a static char buffer to hold data for various types. A quote from
> the thread:
>
> "I thought variant just static_cast<char*>  to void* then from void* to
> T*.  The char* is for the memory buffer in boost::aligned_storage."
>
> which indeed what it does. However, later in the thread, it is also
> questioned how this would actually solve the strict aliasing rule
> problem, and then there was no answer, except complaints about the
> said rule. I tried to look in the standard for specials cases with
> static_cast and char*/unsigned char* and void*, but I found nothing of
> interest... well, assuming I understood everything where I looked (no
> guaranties :) ). I neither read the cover-to-cover 700+ pages.
>
> So I thought there might be some C++ gurus out here with an answer.

Strict aliasing is a g++ thing, not a standard C++ thing: the standard is The 
Wrong Place to look for info about strict aliasing, it's not there.

Standard C++ does however have rules about alignment.

As a practical matter, if you break your system's alignment rules, then in 
practice you get extreme inefficiency or a program crash.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#6977

On Jun 20, 4:16 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
>
> Strict aliasing is a g++ thing, not a standard C++ thing: the standard is The
> Wrong Place to look for info about strict aliasing, it's not there.

Quoting 3.10-15 from the C++ standard (2003):

"If a program attempts to access the stored value of an object through
an lvalue of other than one of the following
types the behavior is undefined):
— the dynamic type of the object,
— a cv-qualified version of the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to the
dynamic type of the object,
— a type that is the signed or unsigned type corresponding to a cv-
qualified version of the dynamic type of the object,
— an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union),
— a type that is a (possibly cv-qualified) base class type of the
dynamic type of the object,
— a char or unsigned char type."

So what I am reading here?

> Standard C++ does however have rules about alignment.
>
> As a practical matter, if you break your system's alignment rules, then in
> practice you get extreme inefficiency or a program crash.

Of course.

--
Francois Duranleau

[toc] | [prev] | [next] | [standalone]

#6980

* Francois Duranleau, on 20.06.2011 22:29:
> On Jun 20, 4:16 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>>
>> Strict aliasing is a g++ thing, not a standard C++ thing: the standard is The
>> Wrong Place to look for info about strict aliasing, it's not there.
>
> Quoting 3.10-15 from the C++ standard (2003):
>
> "If a program attempts to access the stored value of an object through
> an lvalue of other than one of the following
> types the behavior is undefined):
> — the dynamic type of the object,
> — a cv-qualified version of the dynamic type of the object,
> — a type that is the signed or unsigned type corresponding to the
> dynamic type of the object,
> — a type that is the signed or unsigned type corresponding to a cv-
> qualified version of the dynamic type of the object,
> — an aggregate or union type that includes one of the aforementioned
> types among its members (including, recursively, a member of a
> subaggregate or contained union),
> — a type that is a (possibly cv-qualified) base class type of the
> dynamic type of the object,
> — a char or unsigned char type."
>
> So what I am reading here?

A flawed attempt at enumerating the ways, which attempt was/is presumably the 
perceived rationale for g++ "strict aliasing".


>> Standard C++ does however have rules about alignment.
>>
>> As a practical matter, if you break your system's alignment rules, then in
>> practice you get extreme inefficiency or a program crash.
>
> Of course.

Well, that's all, if your data is correct representation of the object.

Just tell g++ to shut up. :-)


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#6981

On Jun 20, 2:27 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * Francois Duranleau, on 20.06.2011 22:29:
>
>
>
>
>
>
>
>
>
> > On Jun 20, 4:16 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> > +use...@gmail.com>  wrote:
>
> >> Strict aliasing is a g++ thing, not a standard C++ thing: the standard is The
> >> Wrong Place to look for info about strict aliasing, it's not there.
>
> > Quoting 3.10-15 from the C++ standard (2003):
>
> > "If a program attempts to access the stored value of an object through
> > an lvalue of other than one of the following
> > types the behavior is undefined):
> > — the dynamic type of the object,
> > — a cv-qualified version of the dynamic type of the object,
> > — a type that is the signed or unsigned type corresponding to the
> > dynamic type of the object,
> > — a type that is the signed or unsigned type corresponding to a cv-
> > qualified version of the dynamic type of the object,
> > — an aggregate or union type that includes one of the aforementioned
> > types among its members (including, recursively, a member of a
> > subaggregate or contained union),
> > — a type that is a (possibly cv-qualified) base class type of the
> > dynamic type of the object,
> > — a char or unsigned char type."
>
> > So what I am reading here?
>
> A flawed attempt at enumerating the ways, which attempt was/is presumably the
> perceived rationale for g++ "strict aliasing".
>
> >> Standard C++ does however have rules about alignment.
>
> >> As a practical matter, if you break your system's alignment rules, then in
> >> practice you get extreme inefficiency or a program crash.
>
> > Of course.
>
> Well, that's all, if your data is correct representation of the object.
>
> Just tell g++ to shut up. :-)

The C standards committee disagrees with you good sir.

[toc] | [prev] | [next] | [standalone]

#6984

* Joshua Maurice, on 20.06.2011 23:37:
>
> The C standards committee disagrees with you good sir.

I rather doubt that the C standards committee are discussing my C++ Usenet 
postings (or even my C Usenet postings).

But perhaps relevant quotes from the C standard could be useful to the OP, in 
order to relate to the g++ compiler?


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#6987

On Jun 20, 3:31 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * Joshua Maurice, on 20.06.2011 23:37:
>
>
>
> > The C standards committee disagrees with you good sir.
>
> I rather doubt that the C standards committee are discussing my C++ Usenet
> postings (or even my C Usenet postings).
>
> But perhaps relevant quotes from the C standard could be useful to the OP, in
> order to relate to the g++ compiler?

From some of the recent defect reports and their resolutions which
I've been reading, it's clear that the C standards committee does
intend the simple reading of the strict aliasing rules, that you may
not access an object with a differently typed lvalue, unless that
lvalue is char or unsigned char. Of course, it's playing hell with
unions, and then there's my defect (which hasn't made it to defect
status yet) about userspace general purpose memory pooling allocators
in that comp.std.c++ thread. (I even tried to bring this over to
comp.std.c, and the discussion went nowhere fast for 70+ posts.) I
hope someone who can do something about it saw one of the two
discussions, and fixes it the right way.

[toc] | [prev] | [next] | [standalone]

#6982

Alf P. Steinbach /Usenet wrote:

> * Francois Duranleau, on 20.06.2011 22:29:
>> On Jun 20, 4:16 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
>> +use...@gmail.com>  wrote:
>>>
>>> Strict aliasing is a g++ thing, not a standard C++ thing: the standard
>>> is The Wrong Place to look for info about strict aliasing, it's not
>>> there.
>>
>> Quoting 3.10-15 from the C++ standard (2003):
>>
>> "If a program attempts to access the stored value of an object through
>> an lvalue of other than one of the following
>> types the behavior is undefined):
>> ? the dynamic type of the object,
>> ? a cv-qualified version of the dynamic type of the object,
>> ? a type that is the signed or unsigned type corresponding to the
>> dynamic type of the object,
>> ? a type that is the signed or unsigned type corresponding to a cv-
>> qualified version of the dynamic type of the object,
>> ? an aggregate or union type that includes one of the aforementioned
>> types among its members (including, recursively, a member of a
>> subaggregate or contained union),
>> ? a type that is a (possibly cv-qualified) base class type of the
>> dynamic type of the object,
>> ? a char or unsigned char type."
>>
>> So what I am reading here?
> 
> A flawed attempt at enumerating the ways, which attempt was/is presumably
> the perceived rationale for g++ "strict aliasing".

What is the flaw?

I don't think the flaw is obvious (it isn't to me). As evidence (not that it 
isn't flawed, but that's it is not _obviously_ flawed) I would offer that an 
adapted version of the list made it into n3291 as 3.10/10. So, it appears, 
the committee did not see a flaw; or is there a core issue about this that I 
am unaware of? or is the flaw just fixed by passing to glvalues etc.?


Best,

Kai-Uwe Bux

[toc] | [prev] | [next] | [standalone]

#6985

* Kai-Uwe Bux, on 20.06.2011 23:38:
> Alf P. Steinbach /Usenet wrote:
>
>> * Francois Duranleau, on 20.06.2011 22:29:
>>> On Jun 20, 4:16 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
>>> +use...@gmail.com>   wrote:
>>>>
>>>> Strict aliasing is a g++ thing, not a standard C++ thing: the standard
>>>> is The Wrong Place to look for info about strict aliasing, it's not
>>>> there.
>>>
>>> Quoting 3.10-15 from the C++ standard (2003):
>>>
>>> "If a program attempts to access the stored value of an object through
>>> an lvalue of other than one of the following
>>> types the behavior is undefined):
>>> ? the dynamic type of the object,
>>> ? a cv-qualified version of the dynamic type of the object,
>>> ? a type that is the signed or unsigned type corresponding to the
>>> dynamic type of the object,
>>> ? a type that is the signed or unsigned type corresponding to a cv-
>>> qualified version of the dynamic type of the object,
>>> ? an aggregate or union type that includes one of the aforementioned
>>> types among its members (including, recursively, a member of a
>>> subaggregate or contained union),
>>> ? a type that is a (possibly cv-qualified) base class type of the
>>> dynamic type of the object,
>>> ? a char or unsigned char type."
>>>
>>> So what I am reading here?
>>
>> A flawed attempt at enumerating the ways, which attempt was/is presumably
>> the perceived rationale for g++ "strict aliasing".
>
> What is the flaw?

Just as an example that the above list does not cover everything, the intro to 
classes says that if class A is a POD, and its first member is a double, say, 
then if  you have a pointer to an A then you can reinterpret_cast it to pointer 
to double to access that first member. It's for C compatibility.

And that's not covered by the list, i.e. there's at least one engine stutter: 
the list says it's UB, later on in the standard it's said to be well-defined. ;-)

I don't know exactly what the flaw or set of flaws is, in the sense of not 
knowing exactly why an engine stutters (i.e., cause). Perhaps just the attempt 
to cover everything. It has been discussed at length, many times, as I recall 
without any good consensus, but it hould be possible to find those discussions.


> I don't think the flaw is obvious (it isn't to me). As evidence (not that it
> isn't flawed, but that's it is not _obviously_ flawed) I would offer that an
> adapted version of the list made it into n3291 as 3.10/10. So, it appears,
> the committee did not see a flaw; or is there a core issue about this that I
> am unaware of? or is the flaw just fixed by passing to glvalues etc.?

The committee is not perfect, nor does it have the capacity to deal with everything.

I think there's a lot of flawed stuff migrating straight over into the new standard.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#7003

On Jun 20, 6:46 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * Kai-Uwe Bux, on 20.06.2011 23:38:
>
> > Alf P. Steinbach /Usenet wrote:
>
> >> * Francois Duranleau, on 20.06.2011 22:29:
>
> >>> Quoting 3.10-15 from the C++ standard (2003):
>
> >>> "If a program attempts to access the stored value of an object through
> >>> an lvalue of other than one of the following
> >>> types the behavior is undefined):
> >>> ? the dynamic type of the object,
> >>> ? a cv-qualified version of the dynamic type of the object,
> >>> ? a type that is the signed or unsigned type corresponding to the
> >>> dynamic type of the object,
> >>> ? a type that is the signed or unsigned type corresponding to a cv-
> >>> qualified version of the dynamic type of the object,
> >>> ? an aggregate or union type that includes one of the aforementioned
> >>> types among its members (including, recursively, a member of a
> >>> subaggregate or contained union),
> >>> ? a type that is a (possibly cv-qualified) base class type of the
> >>> dynamic type of the object,
> >>> ? a char or unsigned char type."
>
> >>> So what I am reading here?
>
> >> A flawed attempt at enumerating the ways, which attempt was/is presumably
> >> the perceived rationale for g++ "strict aliasing".
>
> > What is the flaw?
>
> Just as an example that the above list does not cover everything, the intro to
> classes says that if class A is a POD, and its first member is a double, say,
> then if  you have a pointer to an A then you can reinterpret_cast it to pointer
> to double to access that first member. It's for C compatibility.
>
> And that's not covered by the list, i.e. there's at least one engine stutter:
> the list says it's UB, later on in the standard it's said to be well-defined. ;-)

Well, actually, it is covered by this point:

"- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union)"

although not very clearly.

--
Francois Duranleau

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web