Let's "switch" to Something Else
-
I don't think it would, as it's doing the + and shift manually. If it was just
switch(recv[0])then it would be endian vulnerable. In the absence of language or framework features that allow you to switch on a string, I have no problem with this.You've missed the point ... all multibyte char literals are endian-sensitive. To make it endian-insensitive, it should be
#define VB(a,b,c) (((((a)<<8)+(b))<<8)+(c))
verb = VB(upper[curr->recv[0]], upper[curr->recv[1]], upper[curr->recv[2]]);
switch (verb)
{
case VB('C','M','D'):
... -
That's how you handle tags in ICC profiles, for example. It's a perfectly reasonable thing to do.
Tom Delany wrote:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
Still one of my favorite sigs on CP.
Software Zen:
delete this; -
'Sensibility' of a particular approach always depends upon the problem being solved. Making code endian-insensitive is necessary only if you plan on porting it between different endian environments.
Software Zen:
delete this; -
You've missed the point ... all multibyte char literals are endian-sensitive. To make it endian-insensitive, it should be
#define VB(a,b,c) (((((a)<<8)+(b))<<8)+(c))
verb = VB(upper[curr->recv[0]], upper[curr->recv[1]], upper[curr->recv[2]]);
switch (verb)
{
case VB('C','M','D'):
... -
I have no idea which of the things I wrote are the subject of your "oh really", but all of them are correct. As for the rest, it's a non sequitur. Both *recv and multi-char literals are endian-sensitive, so you appear to have committed a fallacy of affirmation of the consequent ... a rather basic failure of logic. But if you want to go around switching on 4-char literals thinking that it's portable, be my guest ... just don't do it in any code that might affect my life.
-
It's in a thread where it's listening for something from a TCPIP connection (sort of a command channel). It's low-volume, and as such, I don't think the "cleverness" is warranted. And no, it's not commented at all. It's not that I don't understand what he was doing. I just think he was being too clever for his own good. And in the (unlikely?) event that the code is ever ported to a big-endian system, it would be completely broken.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
A wee bit of commmenting would be nice, but other than that I cannot see a problem here. As for porting to big-endian system: First of all, that will never happen. Secondly, there will be more places to fix if it did happen. Thirdly, the code is platform-restricted anyway (to Windows), so there is not a problem...:cool:
-
C++ code. This is either brilliant, or just bloody awful. I'm coming down on the side of "bloody awful": recv in the curr structure below is declared as:
BYTE recv\[64\]; DWORD verb; ... verb = (upper\[curr->recv\[0\]\] << 24) + (upper\[curr->recv\[1\]\] << 16) + (upper\[curr->recv\[2\]\] << 8) + 0x20; switch (verb) { case 'CMD ': ... break; case 'MON ': ... break; case 'END ': ... break; case 'EXT ': ... break; default: ... break; }WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
?? what's wrong with it?
-
You've missed the point ... all multibyte char literals are endian-sensitive. To make it endian-insensitive, it should be
#define VB(a,b,c) (((((a)<<8)+(b))<<8)+(c))
verb = VB(upper[curr->recv[0]], upper[curr->recv[1]], upper[curr->recv[2]]);
switch (verb)
{
case VB('C','M','D'):
...You're not proposing he should use VB are you?
-
A wee bit of commmenting would be nice, but other than that I cannot see a problem here. As for porting to big-endian system: First of all, that will never happen. Secondly, there will be more places to fix if it did happen. Thirdly, the code is platform-restricted anyway (to Windows), so there is not a problem...:cool:
Why is that code platform-restricted to Windows? I've seen DWORDs on many platforms, so there's really nothing here to suggest that.
-
Why is that code platform-restricted to Windows? I've seen DWORDs on many platforms, so there's really nothing here to suggest that.
-
C++ code. This is either brilliant, or just bloody awful. I'm coming down on the side of "bloody awful": recv in the curr structure below is declared as:
BYTE recv\[64\]; DWORD verb; ... verb = (upper\[curr->recv\[0\]\] << 24) + (upper\[curr->recv\[1\]\] << 16) + (upper\[curr->recv\[2\]\] << 8) + 0x20; switch (verb) { case 'CMD ': ... break; case 'MON ': ... break; case 'END ': ... break; case 'EXT ': ... break; default: ... break; }WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
I suppose he didn't liked If - else- ifs...
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
C++ code. This is either brilliant, or just bloody awful. I'm coming down on the side of "bloody awful": recv in the curr structure below is declared as:
BYTE recv\[64\]; DWORD verb; ... verb = (upper\[curr->recv\[0\]\] << 24) + (upper\[curr->recv\[1\]\] << 16) + (upper\[curr->recv\[2\]\] << 8) + 0x20; switch (verb) { case 'CMD ': ... break; case 'MON ': ... break; case 'END ': ... break; case 'EXT ': ... break; default: ... break; }WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
It's sort of both... it'd be properly brilliant if the "verb =" line were commented...
-
It's in a thread where it's listening for something from a TCPIP connection (sort of a command channel). It's low-volume, and as such, I don't think the "cleverness" is warranted. And no, it's not commented at all. It's not that I don't understand what he was doing. I just think he was being too clever for his own good. And in the (unlikely?) event that the code is ever ported to a big-endian system, it would be completely broken.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Tom Delany wrote:
event that the code is ever ported to a big-endian system, it would be completely broken.
No it wouldn't. The code POSTED would work regardless of that. As mentioned it is a TCP stream so it sequential. The switch statement is using ascii. The only way endianess would matter would be if the stream started to use a different character set. And if it did that it would fail if 1. The character system was not using a 8 bit lower representation of that matched ascii (UTF8 does where UTF16 does not.) 2. AND if the protocol changed. And certainly if item 2 is true then all sorts of problems could result. Such as the rest of the code, following the switch, failing as well.
-
You've missed the point ... all multibyte char literals are endian-sensitive. To make it endian-insensitive, it should be
#define VB(a,b,c) (((((a)<<8)+(b))<<8)+(c))
verb = VB(upper[curr->recv[0]], upper[curr->recv[1]], upper[curr->recv[2]]);
switch (verb)
{
case VB('C','M','D'):
...jibalt wrote:
You've missed the point ... all multibyte char literals are endian-sensitive.
To make it endian-insensitive, it should beThat however ignores the point that the code was written to support a specific protocol over TCP. If the character set of the protocol changed then that would be just one thing that would likely break.
-
C++ code. This is either brilliant, or just bloody awful. I'm coming down on the side of "bloody awful": recv in the curr structure below is declared as:
BYTE recv\[64\]; DWORD verb; ... verb = (upper\[curr->recv\[0\]\] << 24) + (upper\[curr->recv\[1\]\] << 16) + (upper\[curr->recv\[2\]\] << 8) + 0x20; switch (verb) { case 'CMD ': ... break; case 'MON ': ... break; case 'END ': ... break; case 'EXT ': ... break; default: ... break; }WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
I have no idea which of the things I wrote are the subject of your "oh really", but all of them are correct. As for the rest, it's a non sequitur. Both *recv and multi-char literals are endian-sensitive, so you appear to have committed a fallacy of affirmation of the consequent ... a rather basic failure of logic. But if you want to go around switching on 4-char literals thinking that it's portable, be my guest ... just don't do it in any code that might affect my life.
You can use big words all you like, but either 'CMD ' is endian sensitive, i.e. it is the byte stream 'C', 'M', 'D', ' ' on one system and ' ', 'D', 'M', 'C' on another, or it isn't, i.e. it's always 'C', 'M', 'D', ' ' and therefore maps to a different integer. In the first case, *recv won't be correct because the byte stream you're checking for is always the same, but the code in the original example would be, because it manually makes the integer in the big-endian manner, and that will be the value that the constant has if it switches the byte order. And if not, *recv will be correct, even if the integer interpretation of that value will be different. There is one good argument you could have deployed, which is that the standard doesn't actually define whether a multi character constant refers to byte order or integer value. But if it has a consistent meaning in real world compilers, that doesn't really matter.
-
C++ code. This is either brilliant, or just bloody awful. I'm coming down on the side of "bloody awful": recv in the curr structure below is declared as:
BYTE recv\[64\]; DWORD verb; ... verb = (upper\[curr->recv\[0\]\] << 24) + (upper\[curr->recv\[1\]\] << 16) + (upper\[curr->recv\[2\]\] << 8) + 0x20; switch (verb) { case 'CMD ': ... break; case 'MON ': ... break; case 'END ': ... break; case 'EXT ': ... break; default: ... break; }WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
In my eyes it is ugly, but one of the easies way to compare strings (up to 8 bytes) in a most efficient way. If it's needed and documented ... ok. I recently saw a very strange way to copy an object in C++:
-
the class defines all its data member attributes within 64 Byte
-
the data member attributes are ordered to use alignment efficently
-
copying the class is done this way (or similar)
C64bitClass src, dst;
// cast the pointer to the source/destination object to __int64 pointers
__int64 *pnSrc = static_cast<__int64*>(&src);
__int64 *pnDst = static_cast<__int64*>(&dst);// copy the first 64bit of the object - the data of the object
*pnDst = *pnSrc;
This really ugly, isn't it!
-
-
You can use big words all you like, but either 'CMD ' is endian sensitive, i.e. it is the byte stream 'C', 'M', 'D', ' ' on one system and ' ', 'D', 'M', 'C' on another, or it isn't, i.e. it's always 'C', 'M', 'D', ' ' and therefore maps to a different integer. In the first case, *recv won't be correct because the byte stream you're checking for is always the same, but the code in the original example would be, because it manually makes the integer in the big-endian manner, and that will be the value that the constant has if it switches the byte order. And if not, *recv will be correct, even if the integer interpretation of that value will be different. There is one good argument you could have deployed, which is that the standard doesn't actually define whether a multi character constant refers to byte order or integer value. But if it has a consistent meaning in real world compilers, that doesn't really matter.
-
jibalt wrote:
You've missed the point ... all multibyte char literals are endian-sensitive.
To make it endian-insensitive, it should beThat however ignores the point that the code was written to support a specific protocol over TCP. If the character set of the protocol changed then that would be just one thing that would likely break.
-
jibalt wrote:
No, I did not ignore your irrelevant point.
Your comments are only relevent if the character set changes - and thus the protocol changed. Thus your comment, in terms of the original question, is irrelevant. And I seriously doubt it would ever be relevant because it presumes that the protocol is compiler dependent. Even if the protocol did specially use a multi-byte character set which varied by OS then then the correct thing for the protocol to do is send a precursor to determine the ordering. Your code presumes and ordering and ignores the possibility that the other end is running on a different OS.