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 2 of 2 — ← Prev page 1 [2]

#7013

* Francois Duranleau, on 21.06.2011 14:03:
> 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.

You have that backwards. In the example above, an `A` object is accessed as a 
`double`. A `double` is not an aggregate or union.

But presumably you would not have posted the article I'm replying to now, if you 
agreed with that.

However, even if it seems to you to be the other way around, consider that the 
standard's list only works one way, while later on in the standard, a two way 
conversion is defined  --  one of those 2 directions is necessarily missing.


Cheers & hth.,

- Alf

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

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

#7021

On Jun 21, 10:19 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * Francois Duranleau, on 21.06.2011 14:03:
>
> > 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:
>
> >>> 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.
>
> You have that backwards. In the example above, an `A` object is accessed as a
> `double`. A `double` is not an aggregate or union.
>
> But presumably you would not have posted the article I'm replying to now, if you
> agreed with that.
>
> However, even if it seems to you to be the other way around, consider that the
> standard's list only works one way, while later on in the standard, a two way
> conversion is defined  --  one of those 2 directions is necessarily missing.

Indeed, I misread your example, sorry. What was I thinking.

Do you know where in the standard where we can find that two way
conversion definition?

--
Francois Duranleau

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

#7042

* Francois Duranleau, on 21.06.2011 18:08:
> On Jun 21, 10:19 am, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>> * Francois Duranleau, on 21.06.2011 14:03:
>>
>>> 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:
>>
>>>>> 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.
>>
>> You have that backwards. In the example above, an `A` object is accessed as a
>> `double`. A `double` is not an aggregate or union.
>>
>> But presumably you would not have posted the article I'm replying to now, if you
>> agreed with that.
>>
>> However, even if it seems to you to be the other way around, consider that the
>> standard's list only works one way, while later on in the standard, a two way
>> conversion is defined  --  one of those 2 directions is necessarily missing.
>
> Indeed, I misread your example, sorry. What was I thinking.
>
> Do you know where in the standard where we can find that two way
> conversion definition?

$9.2/17 in the current standard, the crucial wording being "and vice versa".


Cheers & hth.,

- Alf

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

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

#6983

On Jun 20, 9:59 am, Francois Duranleau <xiao.bai.xi...@gmail.com>
wrote:
> 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.

Ok, if you need to convert an actual char buffer to a POD struct, then
I think you're right and you're screwed - you would need to copy the
data byte by byte into an object of dynamic type POD struct.

If you need to go the other way, then a simple cast suffices. You are
allowed to read a POD object through a char lvalue.

Optionally, do you need code portability? gcc -fno-strict-aliasing may
be for you.

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

#6991

"Francois Duranleau" <xiao.bai.xiong@gmail.com> ha scritto nel messaggio
news:f70612e6-c4e9-4166-842a-afc158fba36e@k6g2000yqc.googlegroups.com...

i don't know if this is right, it is only one try it is something about:
----------
#include <stdint.h>
#include <stdlib.h>
#include <iostream.h>

// macro for types
#define  u64  uint64_t
#define  u32  uint32_t
#define  u16  uint16_t
#define  u8    uint8_t
#define  uns  unsigned

// macro for function
#define  P  printf

// macro for keyWords
#define G  goto
#define R  return
#define W  while
#define F  for
#define T  template
#define TN typename

// return u8 offset from type t offset (index)
T<TN t>u32  RetOffset(u32 index, t&   m)
{t     a[2];
 u8   *i,*j;
 u32      k;

 (void) m;
 i=(u8*)a; j=(u8*)(a+1);
 k=j-i;
 P("k==%u\n", k);
 if((int)k<=0) R  -1;  // assurdo?
 R  index*k;   // here how detect overflow?
}

// buf vettore ritornato da malloc o new
// allineato ok per ogni possibile tipo
T<TN t>u32 GetData(t* data, u8*  buf, u32 bufsz ,u32 offset)
{t     a[2], *d;
 u8       *i,*j;
 u32          k;

// problemi nel determinare l'overflow di offsetof
// P("offset=%u sizeof(t)=%u\n", (uns)offset, (uns)sizeof(t));
 if((int)offset<0 || (offset+sizeof(t))>=bufsz)
               R  -1;
 i=(u8*)a; j=(u8*)(a+1);
 k=j-i;
 if((int)k<=0) R  -1;
 k=offset%k;
 if(k!=0)      R  -1;  // non propriamente allineato
 *data=*(t*)(buf+offset);
 R  0;
}

// buf vettore ritornato da malloc o new
// allineato ok per ogni possibile tipo
// trasforma il vettore buf in un vettore di tipi t
// index offset/sizeof(t)
T<TN t>u32 SetData(u8*  buf, u32 bufsz ,u32 offset, t& data)
{t      a[2],*d;
 u8       *i,*j;
 u32          k;

 if(offset+sizeof(t)>=bufsz)
               R  -1;
 i=(u8*)a; j=(u8*)(a+1);
 k=j-i;
 if((int)k<=0) R  -1;
 k=offset%k;
 if(k!=0)      R  -1;
 *(t*)(buf+offset)=data;
 R  0;
}


int  main(void)
{long double  ld0=1.123, ld1=0.0;
 double        d0=2.123,  d1=0.0;
 size_t        s0=12345,  s1=0;
 u8   *buf;
 u32     a, b, c, r;

 buf=(u8*)malloc(1000);
 if(buf==0) R  0;
 a=RetOffset(0,ld0);
 b=RetOffset(4, d0);
 c=RetOffset(16, s0);
 P("a=%u, b=%u, c=%u\n", (uns)a, (uns)b, (uns)c);
 if(a+sizeof(long double)>b)
     {err: P("Trovato errore"); free(buf); R  0;}
 if(b+sizeof(double)>c)    G err;
 if(c+sizeof(size_t)>1000) G err;
 r=SetData(buf,  100, a, ld0); if(r==-1) G  err;
 r=SetData(buf,  100, b,  d0); if(r==-1) G  err;
 r=SetData(buf,  100, c,  s0); if(r==-1) G  err;
 r=GetData(&ld1, buf, 100, a); if(r==-1) G  err;
 r=GetData(&d1,  buf, 100, b); if(r==-1) G  err;
 r=GetData(&s1,  buf, 100, c); if(r==-1) G  err;

 P("ld1=%f  d1=%f s1=%u\n", (double)ld1, d1, (uns) s1);
 free(buf);
 R  0;
}
----------
k==10
k==8
k==4
a=0, b=32, c=64
ld1=1.123000  d1=2.123000 s1=12345
----------------

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

#6994

On 06/21/11 07:12 PM, io_x wrote:
> "Francois Duranleau"<xiao.bai.xiong@gmail.com>  ha scritto nel messaggio
> news:f70612e6-c4e9-4166-842a-afc158fba36e@k6g2000yqc.googlegroups.com...
>
> i don't know if this is right, it is only one try it is something about:
> ----------
> #include<stdint.h>
> #include<stdlib.h>
> #include<iostream.h>
>
> // macro for types
> #define  u64  uint64_t
> #define  u32  uint32_t
> #define  u16  uint16_t
> #define  u8    uint8_t
> #define  uns  unsigned
>
> // macro for function
> #define  P  printf

NO!

-- 
Ian Collins

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web