LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 09-11-2012, 09:58 AM   #16
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,051

Rep: Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100

Quote:
Originally Posted by rstewart View Post
Why not use the pack pragma to set the alignment around the structure? IE:
I have seen some very convincing discussions by gcc experts on why #pragma is worse than __attribute__ for all the things that can be accomplished either way.

I don't remember the details well enough to repeat any of it convincingly, but I was convinced when I read it.

In real projects, it is a lot easier to wrap __attribute__ into a preprocessor macro (to make it properly conditional on the compiler/architecture in a semi portable project) than to do that with #pragma

Quote:
Originally Posted by rajesh180186 View Post
struct s2 {
char a;
int i __attribute__ ((packed));
char b;
int i1;
};
I can't tell whether any of the answers to the reopening of this thread directly answer the question (vs. assume the answer). So my version of that answer is:

In the quoted code, the packed attribute applies only to i and not to i1
Other methods of specifying packed (appearing elsewhere in this thread) apply the packed attribute to the entire struct.

Quote:
Originally Posted by NevemTeve View Post
But please note that this packed stuff:

- is a non-standard extension
That is important to understand when using it.

Quote:
- slows down the processing
That is only sometimes true at all and is rarely significant.

Quote:
- should be avoided
That claim should only be made about fundamentally flawed features, which this certainly is not. This is a very useful extension to C++, which should be used where appropriate. Like any other advanced language feature, it should not be scattered into your code without understanding or valid purpose. But that certainly doesn't mean it should be avoided.

Last edited by johnsfine; 09-11-2012 at 10:10 AM.
 
Old 09-13-2012, 10:03 AM   #17
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,395
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
Quote:
Originally Posted by NevemTeve View Post
But please note that this packed stuff:
- should be avoided
I'd love to avoid it; it's a pain in the pants. What is your recommended alternative where data structures are part of a communications protocol that must be implemented in a consistent cross-platform manner?
--- rod.
 
Old 09-13-2012, 10:27 AM   #18
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,599

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
Code:
typedef struct network_format {
   char aChar;
   int8_t anInt [4]; /* determine byte-order */
} network_format;

typedef struct usable_format {
   char aChar;
   int32_t anInt;
} usable_format;

usable_from_network (usable_format *into, const network_format *from)
{
    into->aChar = from->aChar;
    into->anInt = big2hostl (*(int32_t *)from->anInt); /* pick */
    into->anInt = lit2hostl (*(int32_t *)from->anInt); /* one */
}

network_from_usable (network_format *into, const usable_format *from)
{
    into->aChar = from->aChar;
    *(int32_t *)into->anInt = host2bigl (from->anInt); /* pick */
    *(int32_t *)into->anInt = host2litl (from->anInt); /* one */
}
 
Old 09-13-2012, 12:35 PM   #19
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,395
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
I agree that your suggestion will probably work with respect to packing/alignment (most of your suggestion seems to relate to byte-ordering; a different but related subject) on most architectures, there is nothing to ensure that the packing of the structure will necessarily be the same as a deliberately packed structure. Without the directive not to, padding bytes may be added in any part of the struct. In practice, AFAIK, this would rarely be done between char type elements, but again, this is not guaranteed. Nested structures make the problem even more difficult.
If the solution comes down to breaking every structure element into its respective char-sized elements, then I see the solution as much worse than the problem. I would say that the __attribute__((packed)) directive preserves the purpose of the C struct, by allowing an expression that plainly reflects the nature of the data. Unfortunately, it forces us to know when it is necessary, and embeds architecture-specific features into our source code.
--- rod.
 
Old 09-13-2012, 11:08 PM   #20
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,599

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
Sorry, from your answer I couldn't decide if my answer helped or not. Maybe I should summarize it in plain text: define a special structure only for the network traffic, in this structure every data-element that isn't aligned on its natural alignment (for elementary types it is an offset that is divisible with their size) are to be replaced with char-arrays. To convert from/to this special structure, you have to write conversion functions.

PS: The opposite problem may arise if the network protocol demands gaps between the fields that your compiler may or may not provide; you can add 'char unused_nnn [gapsize]' fields to be sure.

PPS: And obviously types short/int/long long mustn't be used in the network structure, int16_t/int32_t/int64_t are you friends.

Last edited by NevemTeve; 09-14-2012 at 03:11 AM. Reason: typo
 
  


Reply

Tags
gcc


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Converting vop-packed DivX to MPEG CanadianPenguin Linux - Software 5 09-07-2010 04:08 PM
what do all those __attribute__(()) mean? extremeware Programming 3 05-17-2005 03:09 PM
Are ppl buying computers packed with linux. Do u have one? RHLinuxGUY Linux - General 6 09-16-2004 10:06 AM
Grub packed up and left J.Q. Monkey Linux - Newbie 3 01-08-2004 03:21 PM
Diald and mysterious packed daja58 Linux - Networking 0 12-02-2000 05:20 PM


All times are GMT -5. The time now is 02:06 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration