Best practice for parsing data of mixed type?










0














I am wondering whether there is any known best practice/method for parsing mixed type of data packet.



For instance, let's say the data is 10 bytes, and it consists of:



Byte 0-1: manufacturer ID (int)

Byte 2: type (int)

Byte 3-4: device id (ascii char)



I could simply define each data type size and location as #define, and parse it using those defines. But I am wondering if there is any structure to organise this better.










share|improve this question



















  • 1




    is the data binary or text?
    – Swordfish
    Nov 10 '18 at 4:42






  • 2




    If you know the packet definition ahead of time, why not just define a custom struct with all of the required fields?
    – MikeFromCanmore
    Nov 10 '18 at 4:44










  • You have to read the data just like how you wrote it... Since it looks like it is a binary file...
    – Ruks
    Nov 10 '18 at 4:44











  • Does data pass though files for other platforms? Post some sample inputs and exported output data packets. Else this is too broad/unclear.
    – chux
    Nov 10 '18 at 4:44







  • 1




    @Jinsuk, "I could simply define each data type size and location as #define, and parse it using those defines" --> I truly wish you had done that, posted that code and then asked about best practices. It would add information and make for a good post. This one is too broad.
    – chux
    Nov 10 '18 at 5:02















0














I am wondering whether there is any known best practice/method for parsing mixed type of data packet.



For instance, let's say the data is 10 bytes, and it consists of:



Byte 0-1: manufacturer ID (int)

Byte 2: type (int)

Byte 3-4: device id (ascii char)



I could simply define each data type size and location as #define, and parse it using those defines. But I am wondering if there is any structure to organise this better.










share|improve this question



















  • 1




    is the data binary or text?
    – Swordfish
    Nov 10 '18 at 4:42






  • 2




    If you know the packet definition ahead of time, why not just define a custom struct with all of the required fields?
    – MikeFromCanmore
    Nov 10 '18 at 4:44










  • You have to read the data just like how you wrote it... Since it looks like it is a binary file...
    – Ruks
    Nov 10 '18 at 4:44











  • Does data pass though files for other platforms? Post some sample inputs and exported output data packets. Else this is too broad/unclear.
    – chux
    Nov 10 '18 at 4:44







  • 1




    @Jinsuk, "I could simply define each data type size and location as #define, and parse it using those defines" --> I truly wish you had done that, posted that code and then asked about best practices. It would add information and make for a good post. This one is too broad.
    – chux
    Nov 10 '18 at 5:02













0












0








0







I am wondering whether there is any known best practice/method for parsing mixed type of data packet.



For instance, let's say the data is 10 bytes, and it consists of:



Byte 0-1: manufacturer ID (int)

Byte 2: type (int)

Byte 3-4: device id (ascii char)



I could simply define each data type size and location as #define, and parse it using those defines. But I am wondering if there is any structure to organise this better.










share|improve this question















I am wondering whether there is any known best practice/method for parsing mixed type of data packet.



For instance, let's say the data is 10 bytes, and it consists of:



Byte 0-1: manufacturer ID (int)

Byte 2: type (int)

Byte 3-4: device id (ascii char)



I could simply define each data type size and location as #define, and parse it using those defines. But I am wondering if there is any structure to organise this better.







c parsing






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 10 '18 at 4:39









melpomene

58.7k54489




58.7k54489










asked Nov 10 '18 at 4:34









Jinsuk

346




346







  • 1




    is the data binary or text?
    – Swordfish
    Nov 10 '18 at 4:42






  • 2




    If you know the packet definition ahead of time, why not just define a custom struct with all of the required fields?
    – MikeFromCanmore
    Nov 10 '18 at 4:44










  • You have to read the data just like how you wrote it... Since it looks like it is a binary file...
    – Ruks
    Nov 10 '18 at 4:44











  • Does data pass though files for other platforms? Post some sample inputs and exported output data packets. Else this is too broad/unclear.
    – chux
    Nov 10 '18 at 4:44







  • 1




    @Jinsuk, "I could simply define each data type size and location as #define, and parse it using those defines" --> I truly wish you had done that, posted that code and then asked about best practices. It would add information and make for a good post. This one is too broad.
    – chux
    Nov 10 '18 at 5:02












  • 1




    is the data binary or text?
    – Swordfish
    Nov 10 '18 at 4:42






  • 2




    If you know the packet definition ahead of time, why not just define a custom struct with all of the required fields?
    – MikeFromCanmore
    Nov 10 '18 at 4:44










  • You have to read the data just like how you wrote it... Since it looks like it is a binary file...
    – Ruks
    Nov 10 '18 at 4:44











  • Does data pass though files for other platforms? Post some sample inputs and exported output data packets. Else this is too broad/unclear.
    – chux
    Nov 10 '18 at 4:44







  • 1




    @Jinsuk, "I could simply define each data type size and location as #define, and parse it using those defines" --> I truly wish you had done that, posted that code and then asked about best practices. It would add information and make for a good post. This one is too broad.
    – chux
    Nov 10 '18 at 5:02







1




1




is the data binary or text?
– Swordfish
Nov 10 '18 at 4:42




is the data binary or text?
– Swordfish
Nov 10 '18 at 4:42




2




2




If you know the packet definition ahead of time, why not just define a custom struct with all of the required fields?
– MikeFromCanmore
Nov 10 '18 at 4:44




If you know the packet definition ahead of time, why not just define a custom struct with all of the required fields?
– MikeFromCanmore
Nov 10 '18 at 4:44












You have to read the data just like how you wrote it... Since it looks like it is a binary file...
– Ruks
Nov 10 '18 at 4:44





You have to read the data just like how you wrote it... Since it looks like it is a binary file...
– Ruks
Nov 10 '18 at 4:44













Does data pass though files for other platforms? Post some sample inputs and exported output data packets. Else this is too broad/unclear.
– chux
Nov 10 '18 at 4:44





Does data pass though files for other platforms? Post some sample inputs and exported output data packets. Else this is too broad/unclear.
– chux
Nov 10 '18 at 4:44





1




1




@Jinsuk, "I could simply define each data type size and location as #define, and parse it using those defines" --> I truly wish you had done that, posted that code and then asked about best practices. It would add information and make for a good post. This one is too broad.
– chux
Nov 10 '18 at 5:02




@Jinsuk, "I could simply define each data type size and location as #define, and parse it using those defines" --> I truly wish you had done that, posted that code and then asked about best practices. It would add information and make for a good post. This one is too broad.
– chux
Nov 10 '18 at 5:02












2 Answers
2






active

oldest

votes


















2














Best practice it to assume all data from outside the program (e.g. from the user, from a file, from a network, from a different process) is potentially incorrect (and potentially unsafe/malicious).



Then, based on the assumption of "potential incorrectness" define types to distinguish between "unchecked, potential incorrect data" and "checked, known correct data". For your example, you could use uint8_t packet[10]; as the data type for unchecked data and a normal structure (with padding and without __attribute__((packed));) for the checked data. This makes it extremely difficult for a programmer to accidentally use unsafe data when they think they're using safe/checked data.



Of course you will also need code to convert between these data types, which needs to do as many sanity checks as possible (and possibly also worry about things like endianess). For your example these checks could be:



  • are any of the bytes that are supposed to be ASCII characters >= 0x80, and are any of them invalid (e.g. maybe control characters like backspace are not permitted).

  • is the manufacturer ID valid (e.g. maybe there's an enumeration that it needs to match)

  • is the type valid (e.g. maybe there's an enumeration that it needs to match)

Note that this function should return some kind of status to indicate if the conversion was successful or not, and in most cases this status should also give an indication of what the problem was if the conversion wasn't successful (so that the caller can inform the user or log the problem or handle the problem in the most suitable way for the problem). For example, maybe "unknown manufacturer ID" means that the program needs to be updated to handle a new manufacturer and that the data was correct, and "invalid manufacturer ID" means that the data was definitely wrong.






share|improve this answer






















  • Haha I saw __attribute__((packed)) and instinctively downvoted - well, reversed now.
    – Antti Haapala
    Nov 10 '18 at 8:17










  • but perhaps use uint8_t for input.
    – Antti Haapala
    Nov 10 '18 at 8:18










  • @AnttiHaapala: Fixed uint8_t :-)
    – Brendan
    Nov 10 '18 at 13:12


















0














Like this:



struct packet 
uint16_t mfg;
uint8_t type;
uint16_t devid;
__attribute__((packed));


The packed attribute (or your platform's equivalent) is required to avoid implicit padding which doesn't exist in the protocol.



Once you have the above struct, you simply cast (part of) a char array which you received from wherever:



char buf[1000];
(struct packet*)(buf + N);





share|improve this answer




















  • Usual suspects: A complaint C complier may not have any packing ability. Should the packet come from another machine, endian may differ.
    – chux
    Nov 10 '18 at 4:58







  • 1




    Yea. like this :) ...@chux, Presumably if you know the data packet definition, you know what endianness it uses as well. If you need to, you can do your bit/byte-swapping before casting with the struct.
    – MikeFromCanmore
    Nov 10 '18 at 5:07










  • Also, packed is a sure way to cause undefined behaviour in even those compilers that support packing. Casting an array of char to a packet is a violation of strict aliasing rule.
    – Antti Haapala
    Nov 10 '18 at 8:20










  • An example here: stackoverflow.com/a/46790815/918959
    – Antti Haapala
    Nov 10 '18 at 8:22










  • @AnttiHaapala: I did not cast an array of char. I cast buf + N which is a char*. Which to my understanding is allowed to be cast (there's an exception to strict aliasing for char*). What do you think about that?
    – John Zwinck
    Nov 10 '18 at 10:54











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53236024%2fbest-practice-for-parsing-data-of-mixed-type%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














Best practice it to assume all data from outside the program (e.g. from the user, from a file, from a network, from a different process) is potentially incorrect (and potentially unsafe/malicious).



Then, based on the assumption of "potential incorrectness" define types to distinguish between "unchecked, potential incorrect data" and "checked, known correct data". For your example, you could use uint8_t packet[10]; as the data type for unchecked data and a normal structure (with padding and without __attribute__((packed));) for the checked data. This makes it extremely difficult for a programmer to accidentally use unsafe data when they think they're using safe/checked data.



Of course you will also need code to convert between these data types, which needs to do as many sanity checks as possible (and possibly also worry about things like endianess). For your example these checks could be:



  • are any of the bytes that are supposed to be ASCII characters >= 0x80, and are any of them invalid (e.g. maybe control characters like backspace are not permitted).

  • is the manufacturer ID valid (e.g. maybe there's an enumeration that it needs to match)

  • is the type valid (e.g. maybe there's an enumeration that it needs to match)

Note that this function should return some kind of status to indicate if the conversion was successful or not, and in most cases this status should also give an indication of what the problem was if the conversion wasn't successful (so that the caller can inform the user or log the problem or handle the problem in the most suitable way for the problem). For example, maybe "unknown manufacturer ID" means that the program needs to be updated to handle a new manufacturer and that the data was correct, and "invalid manufacturer ID" means that the data was definitely wrong.






share|improve this answer






















  • Haha I saw __attribute__((packed)) and instinctively downvoted - well, reversed now.
    – Antti Haapala
    Nov 10 '18 at 8:17










  • but perhaps use uint8_t for input.
    – Antti Haapala
    Nov 10 '18 at 8:18










  • @AnttiHaapala: Fixed uint8_t :-)
    – Brendan
    Nov 10 '18 at 13:12















2














Best practice it to assume all data from outside the program (e.g. from the user, from a file, from a network, from a different process) is potentially incorrect (and potentially unsafe/malicious).



Then, based on the assumption of "potential incorrectness" define types to distinguish between "unchecked, potential incorrect data" and "checked, known correct data". For your example, you could use uint8_t packet[10]; as the data type for unchecked data and a normal structure (with padding and without __attribute__((packed));) for the checked data. This makes it extremely difficult for a programmer to accidentally use unsafe data when they think they're using safe/checked data.



Of course you will also need code to convert between these data types, which needs to do as many sanity checks as possible (and possibly also worry about things like endianess). For your example these checks could be:



  • are any of the bytes that are supposed to be ASCII characters >= 0x80, and are any of them invalid (e.g. maybe control characters like backspace are not permitted).

  • is the manufacturer ID valid (e.g. maybe there's an enumeration that it needs to match)

  • is the type valid (e.g. maybe there's an enumeration that it needs to match)

Note that this function should return some kind of status to indicate if the conversion was successful or not, and in most cases this status should also give an indication of what the problem was if the conversion wasn't successful (so that the caller can inform the user or log the problem or handle the problem in the most suitable way for the problem). For example, maybe "unknown manufacturer ID" means that the program needs to be updated to handle a new manufacturer and that the data was correct, and "invalid manufacturer ID" means that the data was definitely wrong.






share|improve this answer






















  • Haha I saw __attribute__((packed)) and instinctively downvoted - well, reversed now.
    – Antti Haapala
    Nov 10 '18 at 8:17










  • but perhaps use uint8_t for input.
    – Antti Haapala
    Nov 10 '18 at 8:18










  • @AnttiHaapala: Fixed uint8_t :-)
    – Brendan
    Nov 10 '18 at 13:12













2












2








2






Best practice it to assume all data from outside the program (e.g. from the user, from a file, from a network, from a different process) is potentially incorrect (and potentially unsafe/malicious).



Then, based on the assumption of "potential incorrectness" define types to distinguish between "unchecked, potential incorrect data" and "checked, known correct data". For your example, you could use uint8_t packet[10]; as the data type for unchecked data and a normal structure (with padding and without __attribute__((packed));) for the checked data. This makes it extremely difficult for a programmer to accidentally use unsafe data when they think they're using safe/checked data.



Of course you will also need code to convert between these data types, which needs to do as many sanity checks as possible (and possibly also worry about things like endianess). For your example these checks could be:



  • are any of the bytes that are supposed to be ASCII characters >= 0x80, and are any of them invalid (e.g. maybe control characters like backspace are not permitted).

  • is the manufacturer ID valid (e.g. maybe there's an enumeration that it needs to match)

  • is the type valid (e.g. maybe there's an enumeration that it needs to match)

Note that this function should return some kind of status to indicate if the conversion was successful or not, and in most cases this status should also give an indication of what the problem was if the conversion wasn't successful (so that the caller can inform the user or log the problem or handle the problem in the most suitable way for the problem). For example, maybe "unknown manufacturer ID" means that the program needs to be updated to handle a new manufacturer and that the data was correct, and "invalid manufacturer ID" means that the data was definitely wrong.






share|improve this answer














Best practice it to assume all data from outside the program (e.g. from the user, from a file, from a network, from a different process) is potentially incorrect (and potentially unsafe/malicious).



Then, based on the assumption of "potential incorrectness" define types to distinguish between "unchecked, potential incorrect data" and "checked, known correct data". For your example, you could use uint8_t packet[10]; as the data type for unchecked data and a normal structure (with padding and without __attribute__((packed));) for the checked data. This makes it extremely difficult for a programmer to accidentally use unsafe data when they think they're using safe/checked data.



Of course you will also need code to convert between these data types, which needs to do as many sanity checks as possible (and possibly also worry about things like endianess). For your example these checks could be:



  • are any of the bytes that are supposed to be ASCII characters >= 0x80, and are any of them invalid (e.g. maybe control characters like backspace are not permitted).

  • is the manufacturer ID valid (e.g. maybe there's an enumeration that it needs to match)

  • is the type valid (e.g. maybe there's an enumeration that it needs to match)

Note that this function should return some kind of status to indicate if the conversion was successful or not, and in most cases this status should also give an indication of what the problem was if the conversion wasn't successful (so that the caller can inform the user or log the problem or handle the problem in the most suitable way for the problem). For example, maybe "unknown manufacturer ID" means that the program needs to be updated to handle a new manufacturer and that the data was correct, and "invalid manufacturer ID" means that the data was definitely wrong.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 10 '18 at 13:12

























answered Nov 10 '18 at 7:21









Brendan

12.2k1330




12.2k1330











  • Haha I saw __attribute__((packed)) and instinctively downvoted - well, reversed now.
    – Antti Haapala
    Nov 10 '18 at 8:17










  • but perhaps use uint8_t for input.
    – Antti Haapala
    Nov 10 '18 at 8:18










  • @AnttiHaapala: Fixed uint8_t :-)
    – Brendan
    Nov 10 '18 at 13:12
















  • Haha I saw __attribute__((packed)) and instinctively downvoted - well, reversed now.
    – Antti Haapala
    Nov 10 '18 at 8:17










  • but perhaps use uint8_t for input.
    – Antti Haapala
    Nov 10 '18 at 8:18










  • @AnttiHaapala: Fixed uint8_t :-)
    – Brendan
    Nov 10 '18 at 13:12















Haha I saw __attribute__((packed)) and instinctively downvoted - well, reversed now.
– Antti Haapala
Nov 10 '18 at 8:17




Haha I saw __attribute__((packed)) and instinctively downvoted - well, reversed now.
– Antti Haapala
Nov 10 '18 at 8:17












but perhaps use uint8_t for input.
– Antti Haapala
Nov 10 '18 at 8:18




but perhaps use uint8_t for input.
– Antti Haapala
Nov 10 '18 at 8:18












@AnttiHaapala: Fixed uint8_t :-)
– Brendan
Nov 10 '18 at 13:12




@AnttiHaapala: Fixed uint8_t :-)
– Brendan
Nov 10 '18 at 13:12













0














Like this:



struct packet 
uint16_t mfg;
uint8_t type;
uint16_t devid;
__attribute__((packed));


The packed attribute (or your platform's equivalent) is required to avoid implicit padding which doesn't exist in the protocol.



Once you have the above struct, you simply cast (part of) a char array which you received from wherever:



char buf[1000];
(struct packet*)(buf + N);





share|improve this answer




















  • Usual suspects: A complaint C complier may not have any packing ability. Should the packet come from another machine, endian may differ.
    – chux
    Nov 10 '18 at 4:58







  • 1




    Yea. like this :) ...@chux, Presumably if you know the data packet definition, you know what endianness it uses as well. If you need to, you can do your bit/byte-swapping before casting with the struct.
    – MikeFromCanmore
    Nov 10 '18 at 5:07










  • Also, packed is a sure way to cause undefined behaviour in even those compilers that support packing. Casting an array of char to a packet is a violation of strict aliasing rule.
    – Antti Haapala
    Nov 10 '18 at 8:20










  • An example here: stackoverflow.com/a/46790815/918959
    – Antti Haapala
    Nov 10 '18 at 8:22










  • @AnttiHaapala: I did not cast an array of char. I cast buf + N which is a char*. Which to my understanding is allowed to be cast (there's an exception to strict aliasing for char*). What do you think about that?
    – John Zwinck
    Nov 10 '18 at 10:54
















0














Like this:



struct packet 
uint16_t mfg;
uint8_t type;
uint16_t devid;
__attribute__((packed));


The packed attribute (or your platform's equivalent) is required to avoid implicit padding which doesn't exist in the protocol.



Once you have the above struct, you simply cast (part of) a char array which you received from wherever:



char buf[1000];
(struct packet*)(buf + N);





share|improve this answer




















  • Usual suspects: A complaint C complier may not have any packing ability. Should the packet come from another machine, endian may differ.
    – chux
    Nov 10 '18 at 4:58







  • 1




    Yea. like this :) ...@chux, Presumably if you know the data packet definition, you know what endianness it uses as well. If you need to, you can do your bit/byte-swapping before casting with the struct.
    – MikeFromCanmore
    Nov 10 '18 at 5:07










  • Also, packed is a sure way to cause undefined behaviour in even those compilers that support packing. Casting an array of char to a packet is a violation of strict aliasing rule.
    – Antti Haapala
    Nov 10 '18 at 8:20










  • An example here: stackoverflow.com/a/46790815/918959
    – Antti Haapala
    Nov 10 '18 at 8:22










  • @AnttiHaapala: I did not cast an array of char. I cast buf + N which is a char*. Which to my understanding is allowed to be cast (there's an exception to strict aliasing for char*). What do you think about that?
    – John Zwinck
    Nov 10 '18 at 10:54














0












0








0






Like this:



struct packet 
uint16_t mfg;
uint8_t type;
uint16_t devid;
__attribute__((packed));


The packed attribute (or your platform's equivalent) is required to avoid implicit padding which doesn't exist in the protocol.



Once you have the above struct, you simply cast (part of) a char array which you received from wherever:



char buf[1000];
(struct packet*)(buf + N);





share|improve this answer












Like this:



struct packet 
uint16_t mfg;
uint8_t type;
uint16_t devid;
__attribute__((packed));


The packed attribute (or your platform's equivalent) is required to avoid implicit padding which doesn't exist in the protocol.



Once you have the above struct, you simply cast (part of) a char array which you received from wherever:



char buf[1000];
(struct packet*)(buf + N);






share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 10 '18 at 4:54









John Zwinck

150k16175287




150k16175287











  • Usual suspects: A complaint C complier may not have any packing ability. Should the packet come from another machine, endian may differ.
    – chux
    Nov 10 '18 at 4:58







  • 1




    Yea. like this :) ...@chux, Presumably if you know the data packet definition, you know what endianness it uses as well. If you need to, you can do your bit/byte-swapping before casting with the struct.
    – MikeFromCanmore
    Nov 10 '18 at 5:07










  • Also, packed is a sure way to cause undefined behaviour in even those compilers that support packing. Casting an array of char to a packet is a violation of strict aliasing rule.
    – Antti Haapala
    Nov 10 '18 at 8:20










  • An example here: stackoverflow.com/a/46790815/918959
    – Antti Haapala
    Nov 10 '18 at 8:22










  • @AnttiHaapala: I did not cast an array of char. I cast buf + N which is a char*. Which to my understanding is allowed to be cast (there's an exception to strict aliasing for char*). What do you think about that?
    – John Zwinck
    Nov 10 '18 at 10:54

















  • Usual suspects: A complaint C complier may not have any packing ability. Should the packet come from another machine, endian may differ.
    – chux
    Nov 10 '18 at 4:58







  • 1




    Yea. like this :) ...@chux, Presumably if you know the data packet definition, you know what endianness it uses as well. If you need to, you can do your bit/byte-swapping before casting with the struct.
    – MikeFromCanmore
    Nov 10 '18 at 5:07










  • Also, packed is a sure way to cause undefined behaviour in even those compilers that support packing. Casting an array of char to a packet is a violation of strict aliasing rule.
    – Antti Haapala
    Nov 10 '18 at 8:20










  • An example here: stackoverflow.com/a/46790815/918959
    – Antti Haapala
    Nov 10 '18 at 8:22










  • @AnttiHaapala: I did not cast an array of char. I cast buf + N which is a char*. Which to my understanding is allowed to be cast (there's an exception to strict aliasing for char*). What do you think about that?
    – John Zwinck
    Nov 10 '18 at 10:54
















Usual suspects: A complaint C complier may not have any packing ability. Should the packet come from another machine, endian may differ.
– chux
Nov 10 '18 at 4:58





Usual suspects: A complaint C complier may not have any packing ability. Should the packet come from another machine, endian may differ.
– chux
Nov 10 '18 at 4:58





1




1




Yea. like this :) ...@chux, Presumably if you know the data packet definition, you know what endianness it uses as well. If you need to, you can do your bit/byte-swapping before casting with the struct.
– MikeFromCanmore
Nov 10 '18 at 5:07




Yea. like this :) ...@chux, Presumably if you know the data packet definition, you know what endianness it uses as well. If you need to, you can do your bit/byte-swapping before casting with the struct.
– MikeFromCanmore
Nov 10 '18 at 5:07












Also, packed is a sure way to cause undefined behaviour in even those compilers that support packing. Casting an array of char to a packet is a violation of strict aliasing rule.
– Antti Haapala
Nov 10 '18 at 8:20




Also, packed is a sure way to cause undefined behaviour in even those compilers that support packing. Casting an array of char to a packet is a violation of strict aliasing rule.
– Antti Haapala
Nov 10 '18 at 8:20












An example here: stackoverflow.com/a/46790815/918959
– Antti Haapala
Nov 10 '18 at 8:22




An example here: stackoverflow.com/a/46790815/918959
– Antti Haapala
Nov 10 '18 at 8:22












@AnttiHaapala: I did not cast an array of char. I cast buf + N which is a char*. Which to my understanding is allowed to be cast (there's an exception to strict aliasing for char*). What do you think about that?
– John Zwinck
Nov 10 '18 at 10:54





@AnttiHaapala: I did not cast an array of char. I cast buf + N which is a char*. Which to my understanding is allowed to be cast (there's an exception to strict aliasing for char*). What do you think about that?
– John Zwinck
Nov 10 '18 at 10:54


















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53236024%2fbest-practice-for-parsing-data-of-mixed-type%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Crossroads (UK TV series)

ữḛḳṊẴ ẋ,Ẩṙ,ỹḛẪẠứụỿṞṦ,Ṉẍừ,ứ Ị,Ḵ,ṏ ṇỪḎḰṰọửḊ ṾḨḮữẑỶṑỗḮṣṉẃ Ữẩụ,ṓ,ḹẕḪḫỞṿḭ ỒṱṨẁṋṜ ḅẈ ṉ ứṀḱṑỒḵ,ḏ,ḊḖỹẊ Ẻḷổ,ṥ ẔḲẪụḣể Ṱ ḭỏựẶ Ồ Ṩ,ẂḿṡḾồ ỗṗṡịṞẤḵṽẃ ṸḒẄẘ,ủẞẵṦṟầṓế