From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgw.gov.kz (mgw.gov.kz [89.218.88.242]) by dpdk.org (Postfix) with ESMTP id EB89C5682 for ; Sat, 21 Mar 2015 07:57:13 +0100 (CET) Received: from mgw.gov.kz (mx.ctsat.kz [178.89.4.95]) by mgw.gov.kz with ESMTP id t2L6vC6w014198-t2L6vC6x014198; Sat, 21 Mar 2015 12:57:12 +0600 Received: from EXCASHUB2.rgp.local (192.168.40.53) by EdgeForefront.rgp.local (192.168.40.59) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 21 Mar 2015 12:55:19 +0600 Received: from EXMAILBOX1.rgp.local ([fe80::fd56:efd8:e67e:554d]) by excashub2.rgp.local ([fe80::102a:14d8:89fb:6dc2%11]) with mapi id 14.02.0247.003; Sat, 21 Mar 2015 12:55:31 +0600 From: =?koi8-r?B?9tXNwcLFy8/XIOXSxMXOIO3J0trBx9XMz9fJ3g==?= To: Pawel Wodkowski , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] hash: fix breaking strict-aliasing rules Thread-Index: AQHQYZufuEzf9Z5XU0iWAC/pc0HEa50k8F+AgAGUo9E= Date: Sat, 21 Mar 2015 06:57:05 +0000 Message-ID: <62B92B5760FBDD49B5059B6820A956CF405B447A@exmailbox1.rgp.local> References: , <550C16FB.5050808@intel.com> In-Reply-To: <550C16FB.5050808@intel.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.48.7] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: e_zhumabekov@sts.kz Subject: Re: [dpdk-dev] [PATCH] hash: fix breaking strict-aliasing rules X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 06:57:14 -0000 Hi Pawel, Oops, thanks for the clue. I have a buffer over-read here leading to undefi= ned behaviour. The only solution I see here is to declare uint32_t pointer and evaluate it= to (uint8_t *) data + data_len - (data_len & 0x07). Ideas are welcome. Tha= t would resolve strict-aliasing violation. _____________________ From: Pawel Wodkowski [pawelx.wodkowski@intel.com] Sent: Friday, March 20, 2015 18:47 To: =F6=D5=CD=C1=C2=C5=CB=CF=D7 =E5=D2=C4=C5=CE =ED=C9=D2=DA=C1=C7=D5=CC=CF= =D7=C9=DE; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] hash: fix breaking strict-aliasing rules On 2015-03-18 17:51, Yerden Zhumabekov wrote: > > - switch (7 - (data_len & 0x07)) { > + i =3D 7 - (data_len & 0x07); > + switch (i) { > case 0: > - temp |=3D (uint64_t) *((const uint8_t *)p64 + 6) << 48; > - /* Fallthrough */ > case 1: > - temp |=3D (uint64_t) *((const uint8_t *)p64 + 5) << 40; > - /* Fallthrough */ > case 2: > - temp |=3D (uint64_t) *((const uint8_t *)p64 + 4) << 32; > - temp |=3D *((const uint32_t *)p64); > + temp =3D odd_8byte_mask[i] & *p64; > init_val =3D rte_hash_crc_8byte(temp, init_val); > break; > case 3: > - init_val =3D rte_hash_crc_4byte(*(const uint32_t *)p64, ini= t_val); > - break; > case 4: > - temp |=3D *((const uint8_t *)p64 + 2) << 16; > - /* Fallthrough */ > case 5: > - temp |=3D *((const uint8_t *)p64 + 1) << 8; > - /* Fallthrough */ > case 6: > - temp |=3D *((const uint8_t *)p64); > + temp =3D odd_8byte_mask[i] & *p64; > init_val =3D rte_hash_crc_4byte(temp, init_val); > - /* Fallthrough */ > default: > break; > } > Second thought: is this not an issue here reading 8 bytes by dereferencing *p64 if there is less bytes in buffer? -- Pawel