Am 03.01.2021 um 16:39 schrieb Gerhard Sittig: > Sorry, but I cannot see how this is "a compiler bug".
Well, the C standard doesn't specify how the compiler builds the layout of structs. The GCC add an implementation specific extension with the __attribute__ to force packing of the struct. If the source code specifies to pack and the compiler doesn't pack it is, hmm at least strange. But there comes the -m-ms-bitfield option to the game. I actually curious how this evolved. I didn't found the story behind this. > The number > of leading underscores in the application source code should make > the alarm bells go off, screamingly loud. Do you mean the underscores in __attribute__((__packed__) or did I missed something else? > The proper thing to do is what you suggested. Use structs for > internal application purposes. Translate the data at boundaries > between the application and a communication channel, where one > specific memory layout is expected. Leave the application part as > transparent as it should be, don't "constrain" your application > with the details of a physical transport. BTW using packed > structs in the transport conversion isn't right either, it's as > non-portable as packed structs in application code are. I found this in several OSS projects and use it in my personal applications too. But if the sigrok coding style at least discourages the use, I will improve my idea and use the write_uXX/read_uXX functions for the conversion between transfer layout and information struct in the application. I am not the author/maintainer of the LA-2016 driver, but I hope to contibute to the project. > Moving existing drivers that suffer from portability issues can > be considered low hanging fruit for those who want to help other > users, and unbreak the operation of existing drivers in > environments where they did not work before. Such a proper fix > would no doubt get accepted into mainline, since it's a clear > improvement, not just moving the problem to a different location. So, let's do it. Best regards, Helge _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
