- size of a variable - 15 Updates
| jt@toerring.de (Jens Thoms Toerring): Feb 16 11:35PM > > of you send me your email address (mine isn't munged) and I > > pass it on to the other? > It's true. I'll just add him to the ignore filter. Thank you - I think that's a wise decision. It doesn't look likely that you'll reach any kind of agreement (or even a "we agree to disagree") the way this has been developing. Best regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| woodbrian77@gmail.com: Feb 16 05:40PM -0800 Leigh, please don't swear here. Brian Ebenezer Enterprises http://webEbenezer.net |
| "Öö Tiib" <ootiib@hot.ee>: Feb 16 07:40PM -0800 > Leigh, please don't swear here. Brian, Flibble is kind of calm compared to old times but please still don't beg for unneeded profanities? He is correct that Christopher Pisz wrote that 'uint8_t' is 'unsigned long long' in that other thread. https://groups.google.com/forum/#!msg/comp.lang.c++/zs3HWU6ULVM/u8JXT10XSo4J If something is so boring then please let it be and leave unanswered. |
| ghada glissa <ghadaglissa@gmail.com>: Feb 17 03:54AM -0800 Dear Barry, Thank you for your help > Valid only if CHAR_BIT is 8. I want to ask why should i verify CHAR_BIT is 8 bit, why i don't use uint8_t and i'm sur it is 8 bit. > But then, depending on the types of B and AuthData, I used uint8_t *AuthData uint8_t *B > One thing that might affect your design is whether L is constant. I think L is constant. > In a single execution of the program do all the AuthData have the > same format? yes > In subsequent executions do the AuthData have the same format as > in previous executions? It keep the same format but not the same length. Regards. |
| Martijn Lievaart <m@rtij.nl.invlalid>: Feb 17 01:05PM +0100 On Tue, 17 Feb 2015 03:54:51 -0800, ghada glissa wrote: >> Valid only if CHAR_BIT is 8. > I want to ask why should i verify CHAR_BIT is 8 bit, why i don't use > uint8_t and i'm sur it is 8 bit. Because memcpy works on chars (bytes) and chars (bytes) are not guaranteed to be 8 bits in C. M4 |
| guinness.tony@gmail.com: Feb 17 04:42AM -0800 On Monday, 16 February 2015 13:35:56 UTC, ghada glissa wrote: > message block Bi is a 16-octet string" > AuthData has a variable length, and the Bi will have arithmetic > operations in the following steps. The quoted sentence, above, gives me the impression that you are trying to implement Struik's "CCM*" or one of its close relatives. (That sentence, with the missing space before 'Bt', appears in the Authentication transformation description in his patent, the IETF draft spec, the NIST draft spec, the IEEE adoption spec, etc.). If that is the case, then the B[i] will *not* have arithmetic operations performed on them - just simple bit-manipulation operations (of which XOR is one). Thus you don't need a 128-bit integer - you just need a block of 128 bits. As others have hinted, uint8_t block[16] should be fine (perhaps wrapped in a struct to give it copyability). std::bitset<128> might also be a viable alternative. |
| David Brown <david.brown@hesbynett.no>: Feb 17 02:36PM +0100 On 17/02/15 13:05, Martijn Lievaart wrote: >> uint8_t and i'm sur it is 8 bit. > Because memcpy works on chars (bytes) and chars (bytes) are not > guaranteed to be 8 bits in C. As far as I can understand the details of the standard, there is no (standards compliant) way to have a uint8_t type unless chars are 8-bit on the given platform. In theory, a compiler could provide another independent 8-bit unsigned type for uint8_t that is different from "unsigned char" - but as it must be an integral multiple of "char" in size, and char must be at least 8-bit, then char has to be /exactly/ 8-bit if "uint8_t" exists on a platform. So using <stdint.h> and uint8_t is a perfectly valid way of checking that your chars are 8-bit - you will get a compile-time failure if CHAR_BIT is not 8. Thus if you need to have accurate sizes of types, use the standard sized types, and leave checks on CHAR_BIT to C code of the previous century. |
| Daniel <danielaparker@gmail.com>: Feb 17 07:36AM -0800 On Monday, February 16, 2015 at 6:11:04 PM UTC-5, Jens Thoms Toerring wrote: "The Fibble/Pisz cage fight" It's Flibble, if you please. Daniel |
| jt@toerring.de (Jens Thoms Toerring): Feb 17 04:25PM > On Monday, February 16, 2015 at 6:11:04 PM UTC-5, Jens Thoms Toerring wrote: > "The Fibble/Pisz cage fight" > It's Flibble, if you please. I apologize - it was late in the evening after a longish day. And a beer or two may have been a contributing factor in this outrage;-) Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| drew@furrfu.invalid (Drew Lawson): Feb 17 04:46PM In article <mbtrr7$bcn$1@dont-email.me> >> compounding your mistake rather that admitting to it. Am I wrong? >> /Flibble >I said no such thing. Correct, you thought uint8_t was 8 bytes. >Go quote me in the appropriate post and I will try my best to break it >down to your level of understanding. In article <matglf$alo$2@dont-email.me> Christopher Pisz <nospam@notanaddress.com> writes: -- Drew Lawson What would Brian Boitano do? |
| red floyd <no.spam@its.invalid>: Feb 17 09:11AM -0800 On 2/17/2015 8:25 AM, Jens Thoms Toerring wrote: > And a beer or two may have been a contributing factor in this > outrage;-) > Regards, Jens Clearly, you need to have more sausages with your beer!!! |
| Barry Schwarz <schwarzb@dqel.com>: Feb 17 10:51AM -0800 On Tue, 17 Feb 2015 14:36:20 +0100, David Brown >"unsigned char" - but as it must be an integral multiple of "char" in >size, and char must be at least 8-bit, then char has to be /exactly/ >8-bit if "uint8_t" exists on a platform. While the standard talks about uintN_t with N = 8, 16, 32, and 64, it does not limit the compiler to just those values. The compiler is free to provide a uint9_t type. That such a type would require two bytes on an 8-bit system with some unused bits is just a detail the code generator would need to deal with. (Note that the unused bits are not padding, which is prohibited, since they are not part of the type.) Similarly, what in the standard prevents CHAR_BIT from being 16 and the compiler using any 8 bits in the byte to represent the value of a uint8_t? -- Remove del for email |
| Ian Collins <ian-news@hotmail.com>: Feb 18 08:11AM +1300 Barry Schwarz wrote: > Similarly, what in the standard prevents CHAR_BIT from being 16 and > the compiler using any 8 bits in the byte to represent the value of a > uint8_t? sizeof(uint8_t) being less than 1? -- Ian Collins |
| David Brown <david.brown@hesbynett.no>: Feb 17 08:36PM +0100 On 17/02/15 19:51, Barry Schwarz wrote: > code generator would need to deal with. (Note that the unused bits > are not padding, which is prohibited, since they are not part of the > type.) A compiler can provide any uintN_t and intN_t types, as long as those types follow the rules - it can provide a uint9_t as long as the type has the same sort of wrap on overflow semantics as other unsigned integer types, and as long as there is a corresponding int9_t with two's complement arithmetic. But that does not change the fact that if the compiler provides a valid uint8_t, then CHAR_BIT must be 8 (even though weird things are allowed, if unlikely, such as "signed char" being 8-bit one's complement while "int8_t" is 8-bit two's complement). > Similarly, what in the standard prevents CHAR_BIT from being 16 and > the compiler using any 8 bits in the byte to represent the value of a > uint8_t? The rules of C - a "char" is the smallest addressable unit of memory. |
| Barry Schwarz <schwarzb@dqel.com>: Feb 17 02:51PM -0800 On Tue, 17 Feb 2015 20:36:40 +0100, David Brown >> the compiler using any 8 bits in the byte to represent the value of a >> uint8_t? >The rules of C - a "char" is the smallest addressable unit of memory. That doesn't stop sub-byte bit fields. There is also no restriction in the standard that prohibits multiple objects sharing an address. -- Remove del for email |
| 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. |
No comments:
Post a Comment