Monday, February 16, 2015

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

ghada glissa <ghadaglissa@gmail.com>: Feb 16 04:48AM -0800

Dear all,
 
 
I'm sorry to ask such trivial Questions.
I want to know if there is any type of integer with a size of 16 Bytes because I would like to point to an array with each cell is 16 bytes.
 
Also, i want to know the length of a table (which has a variable size)
when I write :
 
uint8_t *AuthData= new uint8_t[48];
printf("the size of authdata est %d",sizeof(AuthData));
 
it return 8 and not 48 ??
 
so any help please.
 
Regards.
ghada glissa <ghadaglissa@gmail.com>: Feb 16 05:16AM -0800

> char( *p )[][ 16 ]
 
I can't use "char" type because i need to do arithmetic operations (exp: XORing 2 hex number)
Victor Bazarov <v.bazarov@comcast.invalid>: Feb 16 08:23AM -0500

On 2/16/2015 7:48 AM, ghada glissa wrote:
> I'm sorry to ask such trivial Questions.
> I want to know if there is any type of integer with a size of 16
> Bytes
because I would like to point to an array with each cell is 16 bytes.
 
Why is it important for each element of your array to be 16 bytes? The
usual design decisions are made based on what you're going to be doing
with objects. Perhaps you could elaborate on the interface (operations)
in which you see your array elements involved.
 
 
> uint8_t *AuthData= new uint8_t[48];
> printf("the size of authdata est %d",sizeof(AuthData));
 
> it return 8 and not 48 ??
 
The 8 is most likely the size of the pointer on your platform. It is
not unusual for pointers on a 64-bit OS to be 8 bytes.
 
What book on C++ are you reading that doesn't explain how 'sizeof' works?
 
V
--
I do not respond to top-posted replies, please don't ask
ghada glissa <ghadaglissa@gmail.com>: Feb 16 05:35AM -0800

The example that i'm working on says:
 
"Parse the message AuthData as B1 || B2 || ... ||Bt, where each message block Bi is a 16-octet string"
 
AuthData has a variable length, and the Bi will have arithmetic operations in the following steps.
David Brown <david.brown@hesbynett.no>: Feb 16 03:12PM +0100

On 16/02/15 14:16, ghada glissa wrote:
 
>> char( *p )[][ 16 ]
 
> I can't use "char" type because i need to do arithmetic operations
> (exp: XORing 2 hex number)
 
You can do xor and arithmetic on char's.
 
But I strongly recommend you use uint8_t (or other sized uintXX_t types)
rather than char or any non-sized types.
Christopher Pisz <nospam@notanaddress.com>: Feb 16 10:30AM -0600

On 2/16/2015 6:48 AM, ghada glissa wrote:
 
> it return 8 and not 48 ??
 
> so any help please.
 
> Regards.
 
AuthData is a pointer..
 
You called size of on the pointer, so it gave you the size of the
pointer in bytes.
 
You could use std::array instead of a raw array and use its size member
instead. Or you can calculate it yourself if you want to use the raw
array by multiplying the size of the type (uint8_t) by the number of
elements.
ghada glissa <ghadaglissa@gmail.com>: Feb 16 08:40AM -0800

What i'm supposed to do is
 
1) Form the 16-octet B0 field consisting of the 1-octet Flags field,the (15-L)-octet Nonce field, and the L-octet representation of the Length field l(m), as follows:
 
B0 = Flags || Nonce N || l(m).
 
the next step is:
 
2)Parse the message AuthData as B1 || B2 || ... ||Bt, where each message block Bi is a 16-octet string.
 
and the next step is to do some arithmetic operation with all the Bi
 
So i have many problems:
 
1. the 16 bytes variable,(may i use pointer to pointer ??)
2. the wrong use of memcpy : memcpy (B[i],AuthData,16);
3. wrong use of the left shift << operator with AuthData : AuthData<<128;
 
So any help please.
 
Regards.
Vlad from Moscow <vlad.moscow@mail.ru>: Feb 16 09:05AM -0800

I bthink that some structure would be more approproate to this definition.
 
B0 = Flags || Nonce N || l(m).
 
For example
 
struct BaseField
{
std::uint8_t flags;
std::uint8_t nonce[14];
std::uint8_t length;
};
 
So you could use standard container std::vector specialized for this structure. For example
 
#include <iostream>
#include <cstdint>
#include <vector>
 
struct BaseField
{
std::uint8_t flags;
std::uint8_t nonce[14];
std::uint8_t length;
};
 
int main()
{
std::vector<BaseField> v;
 
return 0;
}
On Monday, February 16, 2015 at 7:41:11 PM UTC+3, ghada glissa wrote:
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 16 05:19PM

On 16/02/2015 16:30, Christopher Pisz wrote:
> instead. Or you can calculate it yourself if you want to use the raw
> array by multiplying the size of the type (uint8_t) by the number of
> elements.
 
So you've finally accepted that there is nothing wrong with the sized
typedefs? Progress.
 
/Flibble
Christopher Pisz <nospam@notanaddress.com>: Feb 16 11:39AM -0600

On 2/16/2015 11:19 AM, Mr Flibble wrote:
 
> So you've finally accepted that there is nothing wrong with the sized
> typedefs? Progress.
 
> /Flibble
 
He isn't mixing and matching types here is he?
jt@toerring.de (Jens Thoms Toerring): Feb 16 06:04PM


> 1. the 16 bytes variable,(may i use pointer to pointer ??)
> 2. the wrong use of memcpy : memcpy (B[i],AuthData,16);
> 3. wrong use of the left shift << operator with AuthData : AuthData<<128;
 
Since you seem to be using C++ I'd recommend to create a class,
let's call it 'Byte_Block'. In that class you have an array for
storing your 16 bytes of data. And beside that you implement all
kinds of operations you need to do on whole blocks of 16 bytes,
including e.g. an operator for XOR and whatever else you need.
One of te constructors may take three arguments, a flag,
the Nonce and l(m), from which you construct the block as
needed for point 1.
 
class Byte_Block
{
private:
 
uint8_t m_block[ 16 ];
size_t const m_L = 1; // set this to whatever L is supposed to be,
// just make sure it's not larger than 15
 
public:
 
// Constructor for empty block (initialized to all 0)
 
Byte_Block( )
{
std::fill_n( m_block, 16, 0 );
}
 
// Constructor from flags, Nonce and l(m)
 
Byte_Block( uint8_t flags,
uint8_t const * Nonce,
uint8_t const * lm )
{
m_block[ 0 ] = flags;
std::copy_n( Nonce, 15 - m_L, m_block + 1 );
std::copy_n( lm, m_L, m_block + 16 - m_L );
}
 
// XOR operator (may need some modification if the flags or l(m)
// parts of the blocks must be treated differently)
 
Byte_Block
operator ^ ( Byte_Block const & other ) const
{
Byte_Block result;
for ( size_t i = 0; i < 16, ++i )
result[ i ] = m_block[ i ] ^ other.m_block[ i ];
return result;
}
 
// Single byte read access operator
 
uint8_t
operator [ ] ( size_t pos ) const
{
assert( pos < 16 );
return m_block[ pos ];
}
 
// Single byte write access operator
 
uint8_t &
operator [ ] ( size_t pos )
{
assert( pos < 16 );
return m_nlock[ pos ];
}
};
 
Note: the code has not been testet - not even an attempt to
compile it has been made! So the mistakes all are your's
to find and correct;-)
 
With something like this you will have split up most problems
into nice little sub-problems, which will look a lot easier to
handle than when you try to solve them all at once. Of course,
you will need a couple of other building blocks in that class.
 
Now you can do
 
Byte_Block B1( flags, Nonce
Byte_Block B2( B1 );
std::cout << B1[ 5 ] << std::endl;
B1[ 7 ] = 0xab;
Byte_Block B3 = B1 ^ B2;
 
etc. So, keep the low level details hidden in the class
and otherwise concentrate on the bigger picture. You don't
need no pointers (to pointers), just, if you in- sist a
dynamic array of pointers to Byte_Block objects (but a
std::vector<Byte_Block> probably would be a simpler and
perhaps somewhat cleaner approach since it doesn't re-
quire that you keep track all of the time of how many
of such blocks you've got).
 
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 16 07:04PM

On 16/02/2015 17:39, Christopher Pisz wrote:
>> typedefs? Progress.
 
>> /Flibble
 
> He isn't mixing and matching types here is he?
 
That's a yes then. Next time think before you post tons of bullshit.
 
/Flibble
Christopher Pisz <nospam@notanaddress.com>: Feb 16 01:15PM -0600

On 2/16/2015 1:04 PM, Mr Flibble wrote:
 
>> He isn't mixing and matching types here is he?
 
> That's a yes then. Next time think before you post tons of bullshit.
 
> /Flibble
 
Can you at least go argue your nonsensical points of view in the
appropriate thread?
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 16 07:46PM

On 16/02/2015 19:15, Christopher Pisz wrote:
 
>> /Flibble
 
> Can you at least go argue your nonsensical points of view in the
> appropriate thread?
 
What is nonsense exactly? First you made the mistake of thinking
uint16_t was 16 bytes not 16 bits and then you posted a diatribe
compounding your mistake rather that admitting to it. Am I wrong?
 
/Flibble
Barry Schwarz <schwarzb@dqel.com>: Feb 16 12:10PM -0800

On Mon, 16 Feb 2015 08:40:58 -0800 (PST), ghada glissa
 
>and the next step is to do some arithmetic operation with all the Bi
 
>So i have many problems:
 
>1. the 16 bytes variable,(may i use pointer to pointer ??)
 
You can but why you need to is not immediately obvious to me.
 
>2. the wrong use of memcpy : memcpy (B[i],AuthData,16);
 
Valid only if CHAR_BIT is 8. But then, depending on the types of B
and AuthData, you would want something along the lines of
memcpy(&B[i], &AuthData+i*16, 16);
 
>3. wrong use of the left shift << operator with AuthData : AuthData<<128;
 
Based on my previous comment, this would be unneeded.
 
One thing that might affect your design is whether L is constant. For
every B0 you will need to construct, does the Length field always
occupy the same number of octets. The question has two parts:
In a single execution of the program do all the AuthData have the
same format?
In subsequent executions do the AuthData have the same format as
in previous executions?
 
If you work on a system where CHAR_BIT is 8 (simple to test during
compilation), then you can construct B0 easily using memcpy with:
unsigned char B0[16];
memcpy(B0, Flags, 1);
memcpy(B0+1, Nonce, 15-L);
memcpy(B0+16-L, Length, L);
 
If not, you will have to perform your own bit twiddling using the
bitwise and shift operators. For example, if CHAR_BIT is 16:
unsigned char B0[8], x;
memset(B0, 0, 8);
x = (unsigned)(Flags & 0xff) << 8;
B0[0] |= x;
Then, in a loop you would extract each octet of Nonce and store it in
the next octet of B0. The first would go in the second half of B0[0],
the next in the first half of B0[1], then the second half of B0[1],
etc. Similarly for Length.
 
--
Remove del for email
David Brown <david.brown@hesbynett.no>: Feb 16 10:05PM +0100

On 16/02/15 17:40, ghada glissa wrote:
> 3. wrong use of the left shift << operator with AuthData : AuthData<<128;
 
> So any help please.
 
> Regards.
 
Could you tell us what you are trying to do here? In particular, is
this an exercise in a book or class, or is it something you are learning
on your own? We can help with learning, but we need to know so that we
can give appropriate help.
 
If this is /real/ code, handling some sort of encryption or security,
then /please/ give up now - you are not remotely qualified to work on
security code. It is difficult stuff, because it is vital that there
are no flaws in either the algorithms or the implementations.
 
I am not saying this to criticise your lack of experience - everyone
starts at the beginning. But you don't learn to swim by taking a couple
of lessons and then leaping into the middle of the Atlantic.
Christopher Pisz <nospam@notanaddress.com>: Feb 16 04:44PM -0600

On 2/16/2015 1:46 PM, Mr Flibble wrote:
> uint16_t was 16 bytes not 16 bits and then you posted a diatribe
> compounding your mistake rather that admitting to it. Am I wrong?
 
> /Flibble
 
I said no such thing.
 
Go quote me in the appropriate post and I will try my best to break it
down to your level of understanding.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 16 10:49PM

On 16/02/2015 22:44, Christopher Pisz wrote:
 
> I said no such thing.
 
> Go quote me in the appropriate post and I will try my best to break it
> down to your level of understanding.
 
Either you have memory problems or you are a bald faced liar; either way
the evidence is there.
 
/Flibble
Christopher Pisz <nospam@notanaddress.com>: Feb 16 04:51PM -0600

On 2/16/2015 4:49 PM, Mr Flibble wrote:
 
> Either you have memory problems or you are a bald faced liar; either way
> the evidence is there.
 
> /Flibble
 
Or you're just trolling, since you can't seem to reply in the
appropriate thread, much less quote someone when making false claims
about what they said and didn't say.
Christopher Pisz <nospam@notanaddress.com>: Feb 16 10:23AM -0600

On 2/14/2015 2:07 PM, Jorgen Grahn wrote:
> things through which turned out to be properly flagged as compile-time
> errors in later versions.)
 
> /Jorgen
 
2005 was poop.
2008 did better at following the standard.
2010 follows the standard pre C++11, and they only have parts of C+11 in it.
2012 has more C++11.
2013 has all of it.
Paavo Helde <myfirstname@osa.pri.ee>: Feb 16 11:24AM -0600

Christopher Pisz <nospam@notanaddress.com> wrote in
> 2010 follows the standard pre C++11, and they only have parts of C+11
> in it. 2012 has more C++11.
> 2013 has all of it.
 
Not all of it. See https://msdn.microsoft.com/en-us/library/hh567368.aspx,
it has plenty of "No"-s in the VS2013 column.
Christopher Pisz <nospam@notanaddress.com>: Feb 16 11:42AM -0600

On 2/16/2015 11:24 AM, Paavo Helde wrote:
>> 2013 has all of it.
 
> Not all of it. See https://msdn.microsoft.com/en-us/library/hh567368.aspx,
> it has plenty of "No"-s in the VS2013 column.
 
I stand corrected. Maybe the next one....maybe...
ram@zedat.fu-berlin.de (Stefan Ram): Feb 16 01:10PM

>I would like to point to an array with each cell is 16 bytes.
 
char( *p )[][ 16 ]
 
>when I write :
>uint8_t *AuthData= new uint8_t[48];
>printf("the size of authdata est %d",sizeof(AuthData));
 
#include <iostream>
#include <ostream>
 
int main()
{ char( *p )[ 48 ]=( char( * )[ 48 ])new char[ 48 ];
::std::cout << sizeof *p << '\n'; }
ram@zedat.fu-berlin.de (Stefan Ram): Feb 16 01:39PM

>> char( *p )[][ 16 ]
>I can't use "char" type because i need to do arithmetic operations (exp: XORing 2 hex number)
 
int main()
{ char p[ 16 ]; char q[ 16 ]; char r[ 16 ];
for( int i = 0; i < 16; ++i )r[ i ]= p[ i ]^ q[ i ]; }
legalize+jeeves@mail.xmission.com (Richard): Feb 16 04:13AM

[Please do not mail me a copy of your followup]
 
ram@zedat.fu-berlin.de (Stefan Ram) spake the secret code
 
> So, the publication date might have been
> backdated to be in accordance with the name ISO/IEC 14882:2014.
 
I find it more believable that an international standards body
bureaucracy is sluggish to update its web site.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)