- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Of course proper architectures have a way of expressing this as one opcode (EXTVW IIRC).
Bliss even had a way to code it up angle brackets maybe?
Admin
I'm always using the wrong EMV_ADK_BYTE with the wrong EMV_ADK_NIBBLE and getting the wrong data back without any error.
Admin
Seems I was unaware the * is markup for italic text
Admin
*Nybble. Otherwise the bite/byte pun is meaningless
Admin
This is what you get when people learn to code in abstract languages and then need to work with low level byte operations. How could they know of C struct and union features.
Admin
What's wrong with struct and bitfields ?
Admin
Yep, using struct & union is a standard pattern for this kind of operation. Just need something like this (been a while since I've done low-level dev; my memory may be a bit fuzzy):
struct EMV_ADK { union { uint64 all; struct { uint64 manual_reversal : 4; uint64 refund : 4; uint64 reservation : 4; uint64 tip : 4; // etc... } } }
Admin
Guess I need to figure out how formatting works here.
Admin
Admin
The only reason I can think of for this structure of surprises is if EDV_AFK_REFUSE_NO and siblings - i.e., the actual values being compared against - do, for some reason, have to have specific values. If those aren't used anywhere else in the remaining code except for comparing to these shifticles, I'm stumped as well. (Even if they are, there are better ways, of course.)
Admin
Admin
You are assuming that the order of the data in memory doesn't matter. That might not be the case, it could be the information has come in a binary form from another entity.
Admin
Bitfields in C are not strictly portable--allocation of elements is defined by the ABI, and not all toolchains expose options to override the defined behavior to whatever it is you want. So if the bitfields are only ever used within one application, or only ever with ABIs that are known to provide the same ordering/spanning/packing behavior, then there's no trouble. Otherwise, use them with caution.
For best portability, bitmasks/shifts or other operations where the developer explicitly defines the element ordering are generally preferred.
Admin
At least it's documented?
Admin
Actually, I think it's an ethos.
Admin
This is for embedded systems where the more logical ntohs() and htons() combined with a union would take too long to execute.
Admin
Struct and union technically is not guaranteed to operate correctly by the C standard, so... bitmasks are the "proper" pattern. That said, if you have control of the build process and you know that your environment correctly supports the struct/union then that is a hell of a lot more readable.
Admin
..."Struct and union technically is not guaranteed to operate correctly by the C standard, so... " I would agree, but the code in the original posting isn't very portable either. One should realize that portability doesn't really matter if the implementation is consistent from one module to another. Someone must have put the data in the 64 bit entity (somewhere), and if you use the same structure in both places, it can be implemented differently, but still be "portable".
Yes, it is a mess!
Admin
You work with the facilities provided.
What is your problem, little man? Software, as with life, is not designed specifically with you in mind.
Admin
Formatting doesn't work.
There, fixed that for you.
Admin
WTF is YOUR problem BIG MAN. There ARE NO FACILITIES PROVIDED. The forum does not and probably never will have an "Add Code Sample" button or instructions on how to do so by hand. So I answered his question about how to freaking do it, PRE tags. If I had known you were gonna flame me I woulda just said "View Source". Take a hike nutjob.
Admin
Spare us the moralfagging.
Admin
"Imagine, if you will, that you have 64-bits of data."
I'd rather imagine I'm in a world where people don't obsessively stick hyphens after numbers where they don't belong.
Admin
I think Ross is, in a very funny way, referring to point 2 and 3 of your enumeration.
Maybe you want to elaborate what your problem is?
Admin
You know, apart from the obvious WTF of defining a macro (>> 4 & 0x0F) without parentheses this code actually isn't so bad.
To me the bigger WTF here is everyone (developer/submitter, Remy, readers) assuming that this code is not optimal for the platform it was written for.
In other words, without knowing the code history you can't judge it.
Admin
For point #2, it's easy. If the compiler can handle 64-bit types internally, it can emit code to handle 64-bit types even on architectures that have no native 64-bit support. 64-bit integers weren't introduced with 64-bit computers - compiler support has been around a long time and I've had 64-bit types long before I even had access to ARMs using 64-bit.
Hint: There are compiler support libraries that do this work for you. Missing them can lead to oddball missing defines like __eabi_uldiv32 or other symbols, because the compiler was dealing with something the ARM doesn't natively handle.
As long as you have compiler support, use it. This method works, but it leads to all sorts of oddball bugs if you do mess up the array index and masking parameters. And given how the names are similar, it's very easy to miss and overlook.
Admin
Admin
And what if the platform compiler does not provide such library support?