«

"Ben Kibbey" <> wrote in message
news:...
> "BartC" <> writes:

>> #pragma pack(1)

> Is there a difference between GCC's #pragma pack(1) and
> __attribute__((packed))?

I don't know, but the former is easier to remember. It's more universal
(only gcc seems to know about __attribute__). And the syntax is
self-contained (I believe the attribute has to be part of a declaration,
whether before, somewhere in the middle, or after the declaration, I can't
remember either). It also seems to allow a choice of alignment.

So there's no contest really...

--
Bartc

"BartC" <> writes:

> "Ben Kibbey" <> wrote in message
> news:...
>> "BartC" <> writes:
>
>>> #pragma pack(1)
>
>> Is there a difference between GCC's #pragma pack(1) and
>> __attribute__((packed))?
>
> I don't know, but the former is easier to remember. It's more
> universal (only gcc seems to know about __attribute__). And the syntax
> is self-contained (I believe the attribute has to be part of a
> declaration, whether before, somewhere in the middle, or after the
> declaration, I can't remember either). It also seems to allow a choice
> of alignment.
>
> So there's no contest really...

Yes, __attribute__ is clearly superior!

I know it's not that clear-cut in all situation but there's no contest
for me: __attribute__ is much more flexible. The main advantage being
that you can use #define to remove it altogether or to simply the usage
as much as you want. You avoid a nest of often repeated #if's.

In GCC, you can't use it to push/pop the settings and you can't specify
a pack alignment, but the I've never found either to be particularly
useful. If you do need either then, I agree, no context the other way!

--
Ben.

Ben Bacarisse <> writes:

> Yes, __attribute__ is clearly superior!
>
> I know it's not that clear-cut in all situation but there's no contest
> for me: __attribute__ is much more flexible. The main advantage being
> that you can use #define to remove it altogether or to simply the usage
> as much as you want. You avoid a nest of often repeated #if's.
>
> In GCC, you can't use it to push/pop the settings and you can't specify
> a pack alignment, but the I've never found either to be particularly
> useful. If you do need either then, I agree, no context the other
> way!

But then theres the portability question. I'm sure sure what compilers
support __attribute__ for packing. I've only used GCC and CLang (which
support both).

--
Ben Kibbey

Ben Kibbey <> writes:

> Ben Bacarisse <> writes:
>
>> Yes, __attribute__ is clearly superior!
>>
>> I know it's not that clear-cut in all situation but there's no contest
>> for me: __attribute__ is much more flexible. The main advantage being
>> that you can use #define to remove it altogether or to simply the usage
>> as much as you want. You avoid a nest of often repeated #if's.
>>
>> In GCC, you can't use it to push/pop the settings and you can't specify
>> a pack alignment, but the I've never found either to be particularly
>> useful. If you do need either then, I agree, no context the other
>> way!
>
> But then theres the portability question. I'm sure sure what compilers
> support __attribute__ for packing. I've only used GCC and CLang (which
> support both).

Something that can be #defined is more flexible for portability. If all
C systems support something similar, all you need is one #define per
system. MS compilers have, I believe, __pragma(...) and I'd hope others
have followed this pattern.

I agree that there will appear to be no practical advantage if all the
systems you intend to use support the same #pragma syntax, but I
consider that just a coincidence. The functional syntax is still better
even if there is no practical advantage on some particular set of
implementations.

--
Ben.

Ben Bacarisse <> writes:
> Something that can be #defined is more flexible for portability. If all
> C systems support something similar, all you need is one #define per
> system. MS compilers have, I believe, __pragma(...) and I'd hope others
> have followed this pattern.
>
> I agree that there will appear to be no practical advantage if all the
> systems you intend to use support the same #pragma syntax, but I
> consider that just a coincidence. The functional syntax is still better
> even if there is no practical advantage on some particular set of
> implementations.

I guess what I need to know is if #pragma pack() is standard/portable?
What about #pragma itself?

--
Ben Kibbey

On 9/16/2012 4:07 PM, Ben Bacarisse wrote:
> [...]
> I agree that there will appear to be no practical advantage if all the
> systems you intend to use support the same #pragma syntax, but I
> consider that just a coincidence. The functional syntax is still better
> even if there is no practical advantage on some particular set of
> implementations.

A problem I haven't seen mentioned is the meaning of the number
in `#pragma pack'. It appears the Microsoft compilers treat the
number as a count of bytes, so 1,2,4 call for alignment to one-, two-,
and four-byte boundaries. I've seen a compiler whose analogous
construct used the number as the count of low-order zero bits in the
addresses, so 1,2,4 meant two-, four-, and sixteen-byte alignment;
for one-, two-, and four-byte alignments you'd specify 0,1,2 as the
number in the #pragma.

Some folks take comfort from the Standard's requirement that
unrecognized #pragmas be ignored, but I don't. The problem remains
that if you write a #pragma for Compiler X, a different Compiler Y
might "recognize" it but attach an entirely different meaning ...

--
Eric Sosman
d
"The speed at which the system fails is usually not important."

Ben Kibbey <> writes:

> Ben Bacarisse <> writes:
>> Something that can be #defined is more flexible for portability. If all
>> C systems support something similar, all you need is one #define per
>> system. MS compilers have, I believe, __pragma(...) and I'd hope others
>> have followed this pattern.
>>
>> I agree that there will appear to be no practical advantage if all the
>> systems you intend to use support the same #pragma syntax, but I
>> consider that just a coincidence. The functional syntax is still better
>> even if there is no practical advantage on some particular set of
>> implementations.
>
> I guess what I need to know is if #pragma pack() is standard/portable?
> What about #pragma itself?

The pack pragma is not standard is the sense of being in the language
standard, but the notion of having pragmas is standard. C defines three
pragmas (they all start #pragma STDC ...) but they are all about
floating-point or complex arithmetic.

--
Ben.

On 9/16/2012 4:25 PM, Ben Kibbey wrote:
> Ben Bacarisse <> writes:
>> Something that can be #defined is more flexible for portability. If all
>> C systems support something similar, all you need is one #define per
>> system. MS compilers have, I believe, __pragma(...) and I'd hope others
>> have followed this pattern.
>>
>> I agree that there will appear to be no practical advantage if all the
>> systems you intend to use support the same #pragma syntax, but I
>> consider that just a coincidence. The functional syntax is still better
>> even if there is no practical advantage on some particular set of
>> implementations.
>
> I guess what I need to know is if #pragma pack() is standard/portable?

It's not standard. "Portable" is a fuzzier notion.

> What about #pragma itself?

The Standard describes #pragma (and _Pragma) and describes the
effect of `#pragma STDC ...' forms. Other forms are implementation-
defined.

--
Eric Sosman
d
"The speed at which the system fails is usually not important."

BartC wrote:
> I know this is considered off-topic but perhaps someone's got some
> ideas.
> I have a struct like this with elements all packed:
>
> #pragma pack(1)
>
> typedef struct s {
> short int a;
> char b;
> char c;
> int d;
> } V;
>
> V *p;
>

Is all this banter necessary? Why don't you just fix it and "graduate" to
another level? Seesh. You life-long programmers are quite annoying. Oh wait,
are y'all Viet Nam vets? OK then, my bad. Not that you have less legs, that
is your government's fault. I was going to say something about "I", but your
goverment has you bitched so much that you think that loss of life and limb
is a solution. It isn't. But I won't call it a crime, cuz then I'd get a
public defender and be so damned by that post-menapausal bitch who doesn't
know your leg, from her period.

That, of course, is not to say that "the judge" is in anyway more better.
Hate justly. They ("they") want to outlay hate: so that they have carte
blanch control over everyone's existence. Hate is not bad. Those that do bad
things want to escape "justice". Someone wrongs you, you hate them forever.
They are bad. There is no absolution in "government can do no bad", not
courtney **** defender or the system of violation commonly known as "the
justice system". If I was in charge, I would send them to prison and throw
away the key. Yep, that phoning insurance agent "determining" what happened
and whether they should pay. The examples abound. How about the
court-ordered "psychologist", that has a job, can you imagine, some kind of
crime of existence that is her?

I would throw away the key. Yes I would.

You, of course, are stupid but not knowing is a crime. But they escape
justice by being stupid in appropriate times. It is just a ruse of course:
you are stupid, or you are evil. I "hypothiesize" that very very few people
are stupid. That "theory" makes a lot of people evil.

Stop hating? Why don't you outlaw me hating , you evil ****? Hmm? You're
trying, but I just threw a wrench into your machine of evil. I guess you'll
have to fall back on your less obvious crimes against humanity: flags,
voting, democracy. Next thing you will suggest is that silver-spoon
politicians and their system of bullshit means anything less than crime
against humanity.

A child could do better than you, YOU are the problem, so don't be even try
to turn the tablets on me and start calling me bad. I'm am homeless!
Assholes.

Am 16.09.2012 19:29, schrieb Ben Kibbey:
> Ben Bacarisse <> writes:
>
>> Yes, __attribute__ is clearly superior!
>>
>> I know it's not that clear-cut in all situation but there's no contest
>> for me: __attribute__ is much more flexible. The main advantage being
>> that you can use #define to remove it altogether or to simply the usage
>> as much as you want. You avoid a nest of often repeated #if's.
>>
>> In GCC, you can't use it to push/pop the settings and you can't specify
>> a pack alignment, but the I've never found either to be particularly
>> useful. If you do need either then, I agree, no context the other
>> way!
>
> But then theres the portability question. I'm sure sure what compilers
> support __attribute__ for packing. I've only used GCC and CLang (which
> support both).

Concerning portability the easiest is to wrap this in the C11 syntax
with something like

#define _Alignas(X) __attribute__((__aligned__(X)))

and similar things for the compilers that you encounter.

with that you'd be future proof.

Jens