Compiler-specific preprocessor features

The #pragma directive is a compiler specific directive which compiler 
vendors may use for their own purposes. For instance, a #pragma is often 
used to allow suppression of specific error messages, manage heap and 
stack debugging, etc.

C99 introduced a few standard #pragma directives, taking the form 
#pragma STDC �, which are used to control the floating-point implementation.

// end excerpt from http://en.wikipedia.org/wiki/C_preprocessor

K&R II says that pragmas are implementation-specific.  I caught this 
then out of the corner of my eye.  Where can I read up on what must have 
changed?
-- 
Uno

Almost any kompiler has #pragma pack(x);
so sonsider it a standard-feature!

"Mr. Buffoon" <Buffoon@googlemail.com> writes:
> Almost any kompiler has #pragma pack(x);
> so sonsider it a standard-feature!

You are mistaken; #pragma pack is not a standard feature.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On October 6, 2010 14:13, in comp.lang.c, merrilljensen@q.com wrote:

> Compiler-specific preprocessor features
>=20
> The #pragma directive is a compiler specific directive which compiler=

> vendors may use for their own purposes. For instance, a #pragma is of=
ten
> used to allow suppression of specific error messages, manage heap and=

> stack debugging, etc.
>=20
> C99 introduced a few standard #pragma directives, taking the form
> #pragma STDC =E2=80=A6, which are used to control the floating-point
> #implementation.
>=20
> // end excerpt from http://en.wikipedia.org/wiki/C_preprocessor
>=20
> K&R II says that pragmas are implementation-specific.  I caught this
> then out of the corner of my eye.  Where can I read up on what must h=
ave
> changed?

In the ISO C'99 standard, of course :-)

Copies of the draft of the standard are readily available; google
for "ISO-IEC 9989"

FWIW, here's a copy of the section on the Pragma directive from 9989

  6.10.6 Pragma directive=20
  Semantics
1 A preprocessing directive of the form
      # pragma pp-tokensopt new-line
  where the preprocessing token STDC does not immediately follow pragma=
 in
  the directive (prior to any macro replacement)(^152) causes the=20
  implementation to behave in an implementation-de=EF=AC=81ned manner. =
The behavior
  might cause translation to fail or cause the translator or the result=
ing
  program to behave in a non-conforming manner. Any such pragma that is=
 not
  recognized by the implementation is ignored.
2 If the preprocessing token STDC does immediately follow pragma in the=

  directive (prior to any macro replacement), then no macro replacement=
 is
  performed on the directive, and the directive shall have one of the
  following forms (^153) whose meanings are described elsewhere:
      #pragma STDC FP_CONTRACT on-off-switch
      #pragma STDC FENV_ACCESS on-off-switch
      #pragma STDC CX_LIMITED_RANGE on-off-switch
      on-off-switch: one of
                     ON        OFF    DEFAULT
  Forward references: the FP_CONTRACT pragma (7.12.2), the FENV_ACCESS
  pragma (7.6.1), the CX_LIMITED_RANGE pragma (7.3.4).

  ^ 152) An implementation is not required to perform macro replacement=
 in
  pragmas, but it is permitted except for in standard pragmas (where ST=
DC
  immediately follows pragma). If the result of macro replacement in a
  non-standard pragma has the same form as a standard pragma, the behav=
ior
  is still implementation-de=EF=AC=81ned; an implementation is permitte=
d to behave
  as if it were the standard pragma, but is not required to.

 ^ 153) See =E2=80=98=E2=80=98future language directions=E2=80=99=E2=80=
=99 (6.11.8).


--=20
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.c=
a/
----------      Slackware - Because I know what I'm doing.         ----=
--

   Am 06.10.2010 21:16, schrieb Keith Thompson:

>> Almost any kompiler has #pragma pack(x);
>> so sonsider it a standard-feature!

> You are mistaken; #pragma pack is not a standard feature.

*plonk*

On 2010-10-06, Mr. Buffoon <Buffoon@googlemail.com> wrote:
> Almost any kompiler has #pragma pack(x);

That's an interesting claim.  Did you have specific compilers in mind
when you wrote it?

> so sonsider it a standard-feature!

This is not good advice.  You shouldn't consider something standard because
several compilers have it, less still because some guy on the Internet tells
you that "almost any kompiler" has it.

.... Wait.  I'm trying to correct a post by someone called "Mr. Buffoon".

Clearly, I am not yet recovered from this cold.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

"Seebs" <usenet-nospam@seebs.net> wrote in message 
news:slrniapqr2.1s4n.usenet-nospam@guild.seebs.net...
> On 2010-10-06, Mr. Buffoon <Buffoon@googlemail.com> wrote:
>> Almost any kompiler has #pragma pack(x);

>> so sonsider it a standard-feature!
>
> You shouldn't consider something standard because
> several compilers have it, less still because some guy on the Internet 
> tells
> you that "almost any kompiler" has it.


To be fair, he did request that you "sonsider" it.



Brian
-- 
Day 609 of the "no grouchy usenet posts" project. 

[OP replying on experimental unix user, John Smith]


Lew Pitcher wrote:
> On October 6, 2010 14:13, in comp.lang.c, merrilljensen@q.com wrote:
> 
>> Compiler-specific preprocessor features
>>
>> The #pragma directive is a compiler specific directive which compiler
>> vendors may use for their own purposes. For instance, a #pragma is often
>> used to allow suppression of specific error messages, manage heap and
>> stack debugging, etc.
>>
>> C99 introduced a few standard #pragma directives, taking the form
>> #pragma STDC …, which are used to control the floating-point
>> #implementation.
>>
>> // end excerpt from http://en.wikipedia.org/wiki/C_preprocessor
>>
>> K&R II says that pragmas are implementation-specific.  I caught this
>> then out of the corner of my eye.  Where can I read up on what must have
>> changed?
> 
> In the ISO C'99 standard, of course :-)
> 
> Copies of the draft of the standard are readily available; google
> for "ISO-IEC 9989"
> 
> FWIW, here's a copy of the section on the Pragma directive from 9989
> 
>   6.10.6 Pragma directive 
>   Semantics
> 1 A preprocessing directive of the form
>       # pragma pp-tokensopt new-line
>   where the preprocessing token STDC does not immediately follow pragma in
>   the directive (prior to any macro replacement)(^152) causes the 
>   implementation to behave in an implementation-defined manner. The behavior
>   might cause translation to fail or cause the translator or the resulting
>   program to behave in a non-conforming manner. Any such pragma that is not
>   recognized by the implementation is ignored.
> 2 If the preprocessing token STDC does immediately follow pragma in the
>   directive (prior to any macro replacement), then no macro replacement is
>   performed on the directive, and the directive shall have one of the
>   following forms (^153) whose meanings are described elsewhere:
>       #pragma STDC FP_CONTRACT on-off-switch
>       #pragma STDC FENV_ACCESS on-off-switch
>       #pragma STDC CX_LIMITED_RANGE on-off-switch
>       on-off-switch: one of
>                      ON        OFF    DEFAULT
>   Forward references: the FP_CONTRACT pragma (7.12.2), the FENV_ACCESS
>   pragma (7.6.1), the CX_LIMITED_RANGE pragma (7.3.4).
> 
>   ^ 152) An implementation is not required to perform macro replacement in
>   pragmas, but it is permitted except for in standard pragmas (where STDC
>   immediately follows pragma). If the result of macro replacement in a
>   non-standard pragma has the same form as a standard pragma, the behavior
>   is still implementation-defined; an implementation is permitted to behave
>   as if it were the standard pragma, but is not required to.
> 
>  ^ 153) See ‘‘future language directions’’ (6.11.8).
> 
> 

Gosh, Lew, that's thick! Until a few days ago, the only #pragma I ever 
ever saw was
#pragma once
.. I believe Plauger says that this creates idempotence for headers.  Of 
course it *could* do a lot of things for him, as he wrote that when the 
entire thing was still implementation-defined.

I've read up on the perl pragmata.  I didn't get apples thrown at me in 
c.l.f. to suggest it was not a fortran notion.

I forget now where I read that this was for floating point.
-- 
John Smith

Mr. Buffoon wrote:
> Almost any kompiler has #pragma pack(x);
> so sonsider it a standard-feature!

Sagt man "kom pee' luh" for compiler?

The first C texts that I read in German used the word "Kompilator."

I very much enjoy the Janich and Schreiner translation of K&R2.  One 
thing that's different about the "reservierte Worte," is that they're 
all in a different language: english.

Gruss aus New Mexiko,
-- 
John Smith

Default User wrote:
> "Seebs" <usenet-nospam@seebs.net> wrote in message 
> news:slrniapqr2.1s4n.usenet-nospam@guild.seebs.net...
>> On 2010-10-06, Mr. Buffoon <Buffoon@googlemail.com> wrote:
>>> Almost any kompiler has #pragma pack(x);
> 
>>> so sonsider it a standard-feature!
>> You shouldn't consider something standard because
>> several compilers have it, less still because some guy on the Internet 
>> tells
>> you that "almost any kompiler" has it.
> 
> 
> To be fair, he did request that you "sonsider" it.
> 
> 
> 
> Brian

Let's hope for 610.  We'll C.
-- 

In article <8h49nfFvf5U1@mid.individual.net>,
Default User <defaultuserbr@yahoo.com> wrote:
>"Seebs" <usenet-nospam@seebs.net> wrote in message 
>news:slrniapqr2.1s4n.usenet-nospam@guild.seebs.net...
>> On 2010-10-06, Mr. Buffoon <Buffoon@googlemail.com> wrote:
>>> Almost any kompiler has #pragma pack(x);
>
>>> so sonsider it a standard-feature!
>>
>> You shouldn't consider something standard because
>> several compilers have it, less still because some guy on the Internet 
>> tells
>> you that "almost any kompiler" has it.
>
>
>To be fair, he did request that you "sonsider" it.

http://redwing.hutman.net/~mreed/warriorshtm/bigdogmetoo.htm

-- 
Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
an 8 bit operating system based on a 4 bit architecture from a 2 bit company
that can't stand 1 bit of competition.

Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
operating system based on a 4 bit architecture from a 2 bit company that
can't stand 1 bit of competition.

"John Smith" <john@example.invalid> wrote in message 
news:0pmdnXeOEK5ftDDRnZ2dnUVZ5q-dnZ2d@giganews.com...
> Default User wrote:
>> "Seebs" <usenet-nospam@seebs.net> wrote in message 
>> news:slrniapqr2.1s4n.usenet-nospam@guild.seebs.net...
>>> On 2010-10-06, Mr. Buffoon <Buffoon@googlemail.com> wrote:
>>>> Almost any kompiler has #pragma pack(x);
>>
>>>> so sonsider it a standard-feature!
>>> You shouldn't consider something standard because
>>> several compilers have it, less still because some guy on the Internet 
>>> tells
>>> you that "almost any kompiler" has it.
>>
>>
>> To be fair, he did request that you "sonsider" it.

> Let's hope for 610.  We'll C.

Piece of cake.



Brian
-- 
Day 610 of the "no grouchy usenet posts" project.

John Smith wrote:
> Mr. Buffoon wrote:
>> Almost any kompiler has #pragma pack(x);
>> so sonsider it a standard-feature!
> 
> Sagt man "kom pee' luh" for compiler?

Here, we say "compiler" (standard English word) or, less frequent,
"�bersetzer" (German for "translator").


  Stefan

On 10/6/2010 3:12 PM, Mr. Buffoon wrote:
> Almost any kompiler has #pragma pack(x);
> so sonsider it a standard-feature!

There is a world of difference between "widely available (on some 
platforms)" and "standard".

-- 
Kenneth Brody

On 10/6/2010 4:23 PM, Mr. Buffoon wrote:
>   Am 06.10.2010 21:16, schrieb Keith Thompson:
>
>>> Almost any kompiler has #pragma pack(x);
>>> so sonsider it a standard-feature!
>
>> You are mistaken; #pragma pack is not a standard feature.
>
> *plonk*

[sticks fingers in ears]
La, la, la, la, la...  I'm not listening...
[/sticks]

-- 
Kenneth Brody

John Smith wrote:

> Mr. Buffoon wrote:
>> Almost any kompiler has #pragma pack(x);
>> so sonsider it a standard-feature!

IBTD -- RMS, for instance, long resisted to add #pragma to GCC
for two reasons: you can't write #defines that produce #pragmas,
and the #pragmas themselves are less than portable and may lead
to weird results w/out any error or warning message whatsoever.

This has changed some time ago, since the new keyword "_Pragma"
has been introduced (so you can now write #defines producing
_Pragmas), but still, "#pragma pack" isn't part of the official
C standard (please correct me if I'm wrong).  So, while quite a
few compilers with a considerable market share /do/ support the
"#pragma pack" directive, many others do /not/ (or provide this
behaviour through other means), so it's too early to consider it
a real "standard feature".

> Sagt man "kom pee' luh" for compiler?

Not really; it's usually the english word "compiler".  Long time
ago (70s/80s) one could also (rarely!) read the word "Kompiler"
in certain publications, but I guess the pronouncation was still
english; it didn't prevail and never made it to the mainstream.
So, it's either "Compiler" (pronounced as in english, but written
with a capital "C", as it's a noun), or "Übersetzer", the german
word for "translator".  But we mainly say "Compiler" when we're
talking about computer languages.  However, we call the /process/
of translating a program written in one computer language to some
other computer language (incl. assembler or actual machine code)
"Kompilieren" ("'com'pee'lee-ren" -- the apostrophes denote where
to stress the parts of the word; "ren" just as in "renegade").

> The first C texts that I read in German used the word "Kompilator."

I've never actually heard that word, but it sounds funny!  To the
typical German it wouldn'n make any sense, but it rhymes to, e.g.,
"Ventilator" (fan) -- which would be especially confusing if you'd
say "Ich habe gerade den Kompilator angeworfen" ("I've just started
the kompilator") -- but nothing really happens...  ;-)

> I very much enjoy the Janich and Schreiner translation of K&R2.
> One thing that's different about the "reservierte Worte," is that
> they're all in a different language: english.

Yes, they indeed did a really good job!  But given "Axel T's" Unix/C
experience and being a german professor in the U.S., this is not too
much of a surprise, or is it?  :-)

> Gruss aus New Mexiko,

Viele Grüße zurück aus Deutschland!

|Oh, BTW: as this is both, about C and the German language w/ repect
to C, I've omitted the F2-header; please feel free to adjust it for
f'ups, if any.  To further discuss the "german aspects" of this
matter, I'd suggest posting a F2/XP to "de.etc.sprache.misc".]


Cheers,
mike

Am 08.10.2010 00:10, schrieb Michael Schumacher:

> This has changed some time ago, since the new keyword "_Pragma"
> has been introduced (so you can now write #defines producing
> _Pragmas), but still, "#pragma pack" isn't part of the official
> C standard (please correct me if I'm wrong).  So, while quite a
> few compilers with a considerable market share /do/ support the
> "#pragma pack" directive, many others do /not/ (or provide this
> behaviour through other means), so it's too early to consider it
> a real "standard feature".

Falsch, setzen, sechs!!!

Dropping de.comp.lang.c

Michael Schumacher <misc_@gmx.de> writes:
[...]
> IBTD -- RMS, for instance, long resisted to add #pragma to GCC
> for two reasons: you can't write #defines that produce #pragmas,
> and the #pragmas themselves are less than portable and may lead
> to weird results w/out any error or warning message whatsoever.
>
> This has changed some time ago, since the new keyword "_Pragma"
> has been introduced (so you can now write #defines producing
> _Pragmas), but still, "#pragma pack" isn't part of the official
> C standard (please correct me if I'm wrong).

You're right, "#pragma pack" is not defined by any version of the
C standard.

Apparently gcc supports it "[f]or compatibility with Win32".  It takes
an argument, a small power of two that specifies the alignment
(I wouldn't be surprised if other compilers support an incompatible
#pragma with the same name).

All standard-defined #pragmas are of the form:

#pragma STDC ...

As of C99, the standard pragmas are:
    #pragma STDC FP_CONTRACT on-off-switch
    #pragma STDC FENV_ACCESS on-off-switch
    #pragma STDC CX_LIMITED_RANGE on-off-switch
where on-off-switch is one of:
    ON OFF DEFAULT

>                                               So, while quite a
> few compilers with a considerable market share /do/ support the
> "#pragma pack" directive, many others do /not/ (or provide this
> behaviour through other means), so it's too early to consider it
> a real "standard feature".

Agreed -- except that I wouldn't say it's "too early".  The
"#pragma pack" directive is simply non-standard.  Something like
it *might* be added to a future standard, but I know of no serious
proposals to do so.  In particular, the latest C201x draft N1494)
doesn't mention it.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Mr. Buffoon wrote:

> Am 08.10.2010 00:10, schrieb Michael Schumacher:
> 
>> This has changed some time ago, since the new keyword "_Pragma"
>> has been introduced (so you can now write #defines producing
>> _Pragmas), but still, "#pragma pack" isn't part of the official
>> C standard (please correct me if I'm wrong).  So, while quite a
>> few compilers with a considerable market share /do/ support the
>> "#pragma pack" directive, many others do /not/ (or provide this
>> behaviour through other means), so it's too early to consider it
>> a real "standard feature".
> 
> Falsch, setzen, sechs!!!

Du möchtest etwas Sinnvolles zu diesem Thema beitragen?  Nur zu...!


mike

Keith Thompson wrote:

> Michael Schumacher <misc_@gmx.de> writes:
> [...]
>>                                               So, while quite a
>> few compilers with a considerable market share /do/ support the
>> "#pragma pack" directive, many others do /not/ (or provide this
>> behaviour through other means), so it's too early to consider it
>> a real "standard feature".
> 
> Agreed -- except that I wouldn't say it's "too early".  The
> "#pragma pack" directive is simply non-standard.  Something like
> it *might* be added to a future standard, but I know of no serious
> proposals to do so.  In particular, the latest C201x draft N1494)
> doesn't mention it.

And I'd be as surprised as my neighbor's dog if it ever will... ;-)
That's because I simply can't imagine a portable "pack" directive-

Frankly & IMNSHO, using "pack" (where it's available) is pretty much
of a hack -- sure, it might come in handy when you have to deal with
a given problem on a particular platform, but it's also almost /never/
portable, plus it doesn't fix potential byte-sex problems, so you're
probably better off writing specialized "access functions" for these
purposes.  Well, that's at least /my/ experience -- YMMV... :)


mike

On 7 Oct, 23:50, Keith Thompson <ks...@mib.org> wrote:
> Dropping de.comp.lang.c
> Michael Schumacher <mi...@gmx.de> writes:

<snip>

> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 So, while quite a
> > few compilers with a considerable market share /do/ support the
> > "#pragma pack" directive, many others do /not/ (or provide this
> > behaviour through other means), so it's too early to consider it
> > a real "standard feature".
>
> Agreed -- except that I wouldn't say it's "too early". =A0The
> "#pragma pack" directive is simply non-standard. =A0Something like
> it *might* be added to a future standard, but I know of no serious
> proposals to do so. =A0In particular, the latest C201x draft N1494)
> doesn't mention it.

isn't #pragma pack hard (or very expensive) to implement on some
architectures?

Michael Schumacher <misc_@gmx.de> writes:
> Keith Thompson wrote:
>> Michael Schumacher <misc_@gmx.de> writes:
>> [...]
>>>                                               So, while quite a
>>> few compilers with a considerable market share /do/ support the
>>> "#pragma pack" directive, many others do /not/ (or provide this
>>> behaviour through other means), so it's too early to consider it
>>> a real "standard feature".
>> 
>> Agreed -- except that I wouldn't say it's "too early".  The
>> "#pragma pack" directive is simply non-standard.  Something like
>> it *might* be added to a future standard, but I know of no serious
>> proposals to do so.  In particular, the latest C201x draft N1494)
>> doesn't mention it.
>
> And I'd be as surprised as my neighbor's dog if it ever will... ;-)
> That's because I simply can't imagine a portable "pack" directive-
>
> Frankly & IMNSHO, using "pack" (where it's available) is pretty much
> of a hack -- sure, it might come in handy when you have to deal with
> a given problem on a particular platform, but it's also almost /never/
> portable, plus it doesn't fix potential byte-sex problems, so you're
> probably better off writing specialized "access functions" for these
> purposes.  Well, that's at least /my/ experience -- YMMV... :)

In principle, C *could* add a "#pragma pack" or similar feature whose
purpose is to give a hint to the compiler that it should optimize
layouts for space rather than speed of access.  That's what Pascal's
"packed record" and Ada's "pragma Pack(Type_Name)" do.

Such a feature would not be particularly useful for imposing a specified
layout, and on many implementations it would probably be ignored (since
compilers often choose the tightest layout compatible with alignment
requirements anyway).  It might make be useful on platforms where
misaligned accesses are merely slower than aligned access.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On 7 Oct, 23:50, Keith Thompson <ks...@mib.org> wrote:
>> Dropping de.comp.lang.c
>> Michael Schumacher <mi...@gmx.de> writes:
>
> <snip>
>
>> >                                               So, while quite a
>> > few compilers with a considerable market share /do/ support the
>> > "#pragma pack" directive, many others do /not/ (or provide this
>> > behaviour through other means), so it's too early to consider it
>> > a real "standard feature".
>>
>> Agreed -- except that I wouldn't say it's "too early".  The
>> "#pragma pack" directive is simply non-standard.  Something like
>> it *might* be added to a future standard, but I know of no serious
>> proposals to do so.  In particular, the latest C201x draft N1494)
>> doesn't mention it.
>
> isn't #pragma pack hard (or very expensive) to implement on some
> architectures?

It depends on what it's defined to do.  If it just means "optimize
layout for space rather than time", it's trivial: just ignore it.

If it requires, for example:

    offsetof(struct {char c; int i;}, i)) == 1

then it becomes much more difficult on some platforms.  If the member
i is misaligned, think about passing its address to a function that
takes an int* argument; that function has no way of knowing that
its argument might be misaligned, and has to assume the worst.

I just tried at test case with gcc on SPARC, which has strict
alignment requirements.  The compiler quietly accepted a
"#pragma pack(1)" and put the int member at an offset of 1; the
program died at run time with a bus error.  I'd be much happier if
it just rejected the #pragma.

I think that particular form of #pragma was designed for x86-like
systems, where misaligned accesses just slow things down.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnk4lso9s2.fsf@nuthaus.mib.org...
> Michael Schumacher <misc_@gmx.de> writes:
>> Keith Thompson wrote:
>>> Michael Schumacher <misc_@gmx.de> writes:
>>> [...]
>>>>                                               So, while quite a
>>>> few compilers with a considerable market share /do/ support the
>>>> "#pragma pack" directive, many others do /not/ (or provide this
>>>> behaviour through other means), so it's too early to consider it
>>>> a real "standard feature".
>>>
>>> Agreed -- except that I wouldn't say it's "too early".  The
>>> "#pragma pack" directive is simply non-standard.  Something like
>>> it *might* be added to a future standard, but I know of no serious
>>> proposals to do so.  In particular, the latest C201x draft N1494)
>>> doesn't mention it.
>>
>> And I'd be as surprised as my neighbor's dog if it ever will... ;-)
>> That's because I simply can't imagine a portable "pack" directive-
>>
>> Frankly & IMNSHO, using "pack" (where it's available) is pretty much
>> of a hack -- sure, it might come in handy when you have to deal with
>> a given problem on a particular platform, but it's also almost /never/
>> portable, plus it doesn't fix potential byte-sex problems, so you're
>> probably better off writing specialized "access functions" for these
>> purposes.  Well, that's at least /my/ experience -- YMMV... :)
>
> In principle, C *could* add a "#pragma pack" or similar feature whose
> purpose is to give a hint to the compiler that it should optimize
> layouts for space rather than speed of access.  That's what Pascal's
> "packed record" and Ada's "pragma Pack(Type_Name)" do.
>
> Such a feature would not be particularly useful for imposing a specified
> layout, and on many implementations it would probably be ignored (since
> compilers often choose the tightest layout compatible with alignment
> requirements anyway).  It might make be useful on platforms where
> misaligned accesses are merely slower than aligned access.
>

Actually, it serves several purposes.

1) To be able to define a structure that is already carved in stone, for 
example a network packet format that was designed for space.  Or a legacy 
structure that is shared with legacy code.  Before RISC hardware exposed the 
inherent problems with poorly aligned data, there were compilers and 
programmers who didn't pay any attention to alignment and generated 
unaligned structure layouts.

2) Creating structures to map hardware registers.  Usually old hardware, 
since today hardware registers tend to be at least 32-bit aligned and well 
aligned.  Nonetheless there are many old cards that were a hodge podge.   I 
seldom used this, because there can be other restrictions that make it hard 
to use.

3) Making sure that the layout of a shared structure is exact - because it 
will be accessed by things not written in C or compiled by the same C 
compiler for example.  This requires the programmer to take on the 
responsibility for proper alignment.  Of course, in those cases I use a 
seperate tool that is language independent and can generate the proper 
definitions for multiple languages.

For a generic C program that isn't doing any of this, packing is silly.  Let 
the compiler handle it and optimize the layout.

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnfwwgo5e3.fsf@nuthaus.mib.org...
> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>> On 7 Oct, 23:50, Keith Thompson <ks...@mib.org> wrote:
>>> Dropping de.comp.lang.c
>>> Michael Schumacher <mi...@gmx.de> writes:

[...]

>
> I just tried at test case with gcc on SPARC, which has strict
> alignment requirements.  The compiler quietly accepted a
> "#pragma pack(1)" and put the int member at an offset of 1; the
> program died at run time with a bus error.  I'd be much happier if
> it just rejected the #pragma.
>

It's a bad compiler that knows it has a misaligned int, and yet doesn't 
generate the proper code to extract it or write it (in the absence of 
volatile).  Perhaps it's just a very old compiler.  I knew of a UNIX kernel 
that used a very old compiler for it's drivers just because their "current" 
compiler didn't have a proper hardware-specific volatile implementation and 
would act just like you report.

On 10/ 9/10 08:23 AM, Keith Thompson wrote:
> Nick Keighley<nick_keighley_nospam@hotmail.com>  writes:
>>
>> isn't #pragma pack hard (or very expensive) to implement on some
>> architectures?
>
> It depends on what it's defined to do.  If it just means "optimize
> layout for space rather than time", it's trivial: just ignore it.
>
> If it requires, for example:
>
>      offsetof(struct {char c; int i;}, i)) == 1
>
> then it becomes much more difficult on some platforms.  If the member
> i is misaligned, think about passing its address to a function that
> takes an int* argument; that function has no way of knowing that
> its argument might be misaligned, and has to assume the worst.
>
> I just tried at test case with gcc on SPARC, which has strict
> alignment requirements.  The compiler quietly accepted a
> "#pragma pack(1)" and put the int member at an offset of 1; the
> program died at run time with a bus error.  I'd be much happier if
> it just rejected the #pragma.
>
> I think that particular form of #pragma was designed for x86-like
> systems, where misaligned accesses just slow things down.

This (odd alignments on Sparc) is a classic case where packing is 
possible, but expensive.  There are compiler options (at least with Sun 
cc) to get the correct behaviour, ranging form generating the 
appropriate load/store sequences to installing a handler for bus error 
traps.

-- 
Ian Collins

On 10/ 9/10 10:44 AM, FredK wrote:
> "Keith Thompson"<kst-u@mib.org>  wrote:
>>
>> In principle, C *could* add a "#pragma pack" or similar feature whose
>> purpose is to give a hint to the compiler that it should optimize
>> layouts for space rather than speed of access.  That's what Pascal's
>> "packed record" and Ada's "pragma Pack(Type_Name)" do.
>>
>> Such a feature would not be particularly useful for imposing a specified
>> layout, and on many implementations it would probably be ignored (since
>> compilers often choose the tightest layout compatible with alignment
>> requirements anyway).  It might make be useful on platforms where
>> misaligned accesses are merely slower than aligned access.
>>
>
> Actually, it serves several purposes.
>
> 1) To be able to define a structure that is already carved in stone, for
> example a network packet format that was designed for space.  Or a legacy
> structure that is shared with legacy code.  Before RISC hardware exposed the
> inherent problems with poorly aligned data, there were compilers and
> programmers who didn't pay any attention to alignment and generated
> unaligned structure layouts.
>
> 2) Creating structures to map hardware registers.  Usually old hardware,
> since today hardware registers tend to be at least 32-bit aligned and well
> aligned.  Nonetheless there are many old cards that were a hodge podge.   I
> seldom used this, because there can be other restrictions that make it hard
> to use.
>
> 3) Making sure that the layout of a shared structure is exact - because it
> will be accessed by things not written in C or compiled by the same C
> compiler for example.  This requires the programmer to take on the
> responsibility for proper alignment.  Of course, in those cases I use a
> seperate tool that is language independent and can generate the proper
> definitions for multiple languages.

I'd add

4) Testing (embedded) code on a platform with a different native 
alignment (desktop) where the tested code exchanges data with the target 
platform.

-- 
Ian Collins

"FredK" <fred.nospam@dec.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnk4lso9s2.fsf@nuthaus.mib.org...
>> Michael Schumacher <misc_@gmx.de> writes:
>>> Keith Thompson wrote:
>>>> Michael Schumacher <misc_@gmx.de> writes:
>>>> [...]
>>>>>                                               So, while quite a
>>>>> few compilers with a considerable market share /do/ support the
>>>>> "#pragma pack" directive, many others do /not/ (or provide this
>>>>> behaviour through other means), so it's too early to consider it
>>>>> a real "standard feature".
>>>>
>>>> Agreed -- except that I wouldn't say it's "too early".  The
>>>> "#pragma pack" directive is simply non-standard.  Something like
>>>> it *might* be added to a future standard, but I know of no serious
>>>> proposals to do so.  In particular, the latest C201x draft N1494)
>>>> doesn't mention it.
>>>
>>> And I'd be as surprised as my neighbor's dog if it ever will... ;-)
>>> That's because I simply can't imagine a portable "pack" directive-
>>>
>>> Frankly & IMNSHO, using "pack" (where it's available) is pretty much
>>> of a hack -- sure, it might come in handy when you have to deal with
>>> a given problem on a particular platform, but it's also almost /never/
>>> portable, plus it doesn't fix potential byte-sex problems, so you're
>>> probably better off writing specialized "access functions" for these
>>> purposes.  Well, that's at least /my/ experience -- YMMV... :)
>>
>> In principle, C *could* add a "#pragma pack" or similar feature whose
>> purpose is to give a hint to the compiler that it should optimize
>> layouts for space rather than speed of access.  That's what Pascal's
>> "packed record" and Ada's "pragma Pack(Type_Name)" do.
>>
>> Such a feature would not be particularly useful for imposing a specified
>> layout, and on many implementations it would probably be ignored (since
>> compilers often choose the tightest layout compatible with alignment
>> requirements anyway).  It might make be useful on platforms where
>> misaligned accesses are merely slower than aligned access.
>>
>
> Actually, it serves several purposes.
>
> 1) To be able to define a structure that is already carved in stone, for 
> example a network packet format that was designed for space.  Or a legacy 
> structure that is shared with legacy code.  Before RISC hardware exposed the 
> inherent problems with poorly aligned data, there were compilers and 
> programmers who didn't pay any attention to alignment and generated 
> unaligned structure layouts.
>
> 2) Creating structures to map hardware registers.  Usually old hardware, 
> since today hardware registers tend to be at least 32-bit aligned and well 
> aligned.  Nonetheless there are many old cards that were a hodge podge.   I 
> seldom used this, because there can be other restrictions that make it hard 
> to use.
>
> 3) Making sure that the layout of a shared structure is exact - because it 
> will be accessed by things not written in C or compiled by the same C 
> compiler for example.  This requires the programmer to take on the 
> responsibility for proper alignment.  Of course, in those cases I use a 
> seperate tool that is language independent and can generate the proper 
> definitions for multiple languages.

I think you misunderstood my point.  I was talking about a
hypothetical "#pragma pack" that specifically *doesn't* impose
a specified layout; it would simply be a hint that the compiler
should optimize space over time when choosing a layout.  Such a
#pragma would not serve any of the purposes you mention.

Of course a differently defined #pragma could, but I doubt that it
would be practical for C.

> For a generic C program that isn't doing any of this, packing is silly.  Let 
> the compiler handle it and optimize the layout.

Ah, but optimize it how?  There's something to be said for being able
to offer the compiler a hint for whether it should optimize for time
(using strict alignments for faster member access) or space (packing
members more tightly while avoiding breaking anything).  Still, I'm not
convinced it's worth adding as a standard language feature, particularly
since on many platforms either strategy results in exactly the same
layout.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"FredK" <fred.nospam@dec.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnfwwgo5e3.fsf@nuthaus.mib.org...
>> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>>> On 7 Oct, 23:50, Keith Thompson <ks...@mib.org> wrote:
>>>> Dropping de.comp.lang.c
>>>> Michael Schumacher <mi...@gmx.de> writes:
>
> [...]
>
>>
>> I just tried at test case with gcc on SPARC, which has strict
>> alignment requirements.  The compiler quietly accepted a
>> "#pragma pack(1)" and put the int member at an offset of 1; the
>> program died at run time with a bus error.  I'd be much happier if
>> it just rejected the #pragma.
>>
>
> It's a bad compiler that knows it has a misaligned int, and yet doesn't 
> generate the proper code to extract it or write it (in the absence of 
> volatile).  Perhaps it's just a very old compiler.  I knew of a UNIX kernel 
> that used a very old compiler for it's drivers just because their "current" 
> compiler didn't have a proper hardware-specific volatile implementation and 
> would act just like you report.

No, it's not a very old compiler.  I see the problem with gcc 4.5.0
on SPARC/Solaris 9; gcc 4.5.0 was released 6 months ago.

The problem is that it would be nearly impossible for the compiler
to get this right.  int is 4 bytes and requires 4-byte alignment.
Attempting to access a misaligned int causes a bus error.  To handle
this, *any* access to an int object via a pointer would have to
allow for the possibilty that it might be misaligned, either by
using memcpy() or equivalent to copy the object to or from an
aligned location, or perhaps by trapping bus errors.

I suspect that the gcc authors implemented this for Microsoft
compatibility (x86 doesn't have alignment requirements as strict
as SPARC) and didn't bother to make it target-specific.

This is quite simply a compiler bug.  It doesn't actually violate
the C standard, but as a quality-of-implementation issue I just
can't think of any excuse for it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 10/ 9/10 11:58 AM, Keith Thompson wrote:
> "FredK"<fred.nospam@dec.com>  writes:
>
> Of course a differently defined #pragma could, but I doubt that it
> would be practical for C.
>
>> For a generic C program that isn't doing any of this, packing is silly.  Let
>> the compiler handle it and optimize the layout.
>
> Ah, but optimize it how?  There's something to be said for being able
> to offer the compiler a hint for whether it should optimize for time
> (using strict alignments for faster member access) or space (packing
> members more tightly while avoiding breaking anything).  Still, I'm not
> convinced it's worth adding as a standard language feature, particularly
> since on many platforms either strategy results in exactly the same
> layout.

For compilers where this makes sense (typically for embedded systems), 
there are already compiler options to do this.  The option shouldn't be 
embedded in the source code.

-- 
Ian Collins

On 10/ 9/10 12:04 PM, Keith Thompson wrote:
> "FredK"<fred.nospam@dec.com>  writes:
>> "Keith Thompson"<kst-u@mib.org>  wrote:
>>>
>>> I just tried at test case with gcc on SPARC, which has strict
>>> alignment requirements.  The compiler quietly accepted a
>>> "#pragma pack(1)" and put the int member at an offset of 1; the
>>> program died at run time with a bus error.  I'd be much happier if
>>> it just rejected the #pragma.
>>>
>>
>> It's a bad compiler that knows it has a misaligned int, and yet doesn't
>> generate the proper code to extract it or write it (in the absence of
>> volatile).  Perhaps it's just a very old compiler.  I knew of a UNIX kernel
>> that used a very old compiler for it's drivers just because their "current"
>> compiler didn't have a proper hardware-specific volatile implementation and
>> would act just like you report.
>
> No, it's not a very old compiler.  I see the problem with gcc 4.5.0
> on SPARC/Solaris 9; gcc 4.5.0 was released 6 months ago.

For SPARC/Solaris, gcc isn't the compiler of choice.

> The problem is that it would be nearly impossible for the compiler
> to get this right.  int is 4 bytes and requires 4-byte alignment.
> Attempting to access a misaligned int causes a bus error.  To handle
> this, *any* access to an int object via a pointer would have to
> allow for the possibilty that it might be misaligned, either by
> using memcpy() or equivalent to copy the object to or from an
> aligned location, or perhaps by trapping bus errors.

See the the long and comprehensive description of the -xmemalign 
compiler option in the Sun cc man page.  There are a number of 
strategies that can be and are applied.

-- 
Ian Collins

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lntykwmguz.fsf@nuthaus.mib.org...
> "FredK" <fred.nospam@dec.com> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnk4lso9s2.fsf@nuthaus.mib.org...
>>> Michael Schumacher <misc_@gmx.de> writes:
>>>> Keith Thompson wrote:
>>>>> Michael Schumacher <misc_@gmx.de> writes:
>>>>>

[...]

>
> I think you misunderstood my point.  I was talking about a
> hypothetical "#pragma pack" that specifically *doesn't* impose
> a specified layout; it would simply be a hint that the compiler
> should optimize space over time when choosing a layout.  Such a
> #pragma would not serve any of the purposes you mention.
>

Yes.  I misunderstood your point.  As an "optiminzation" hint - it is 
useless.

> Of course a differently defined #pragma could, but I doubt that it
> would be practical for C.
>
>> For a generic C program that isn't doing any of this, packing is silly. 
>> Let
>> the compiler handle it and optimize the layout.
>
> Ah, but optimize it how?  There's something to be said for being able
> to offer the compiler a hint for whether it should optimize for time
> (using strict alignments for faster member access) or space (packing
> members more tightly while avoiding breaking anything).  Still, I'm not
> convinced it's worth adding as a standard language feature, particularly
> since on many platforms either strategy results in exactly the same
> layout.
>

In 1978 when memory was small and expensive, and IO was slow - you can 
forgive people for packed layouts and stuff like RAD50 to save every bit and 
byte.  But memory is cheap, IO is fast, I see little point in optimizing for 
size - with perhaps specific exceptions for embedded designs - but they have 
their own solutions and I doubt very much if they care if there is a 
portable standard "hint" that is probably not going to do what they want 
anyway.

Ian Collins <ian-news@hotmail.com> writes:
> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>> "FredK"<fred.nospam@dec.com>  writes:
>>
>> Of course a differently defined #pragma could, but I doubt that it
>> would be practical for C.
>>
>>> For a generic C program that isn't doing any of this, packing is silly.  Let
>>> the compiler handle it and optimize the layout.
>>
>> Ah, but optimize it how?  There's something to be said for being able
>> to offer the compiler a hint for whether it should optimize for time
>> (using strict alignments for faster member access) or space (packing
>> members more tightly while avoiding breaking anything).  Still, I'm not
>> convinced it's worth adding as a standard language feature, particularly
>> since on many platforms either strategy results in exactly the same
>> layout.
>
> For compilers where this makes sense (typically for embedded systems),
> there are already compiler options to do this.  The option shouldn't
> be embedded in the source code.

Unless you have one type that you want to store a gazillion instances
of in memory (so you want to optimize space), and another with
only a few instances each of which is accessed a gazillion times
(so you want to optimize access time).

On the other hand, it's not clear that it's worthwhile to clutter
the language with too many performance hints.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 10/ 9/10 01:12 PM, Keith Thompson wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>>> "FredK"<fred.nospam@dec.com>   writes:
>>>
>>> Of course a differently defined #pragma could, but I doubt that it
>>> would be practical for C.
>>>
>>>> For a generic C program that isn't doing any of this, packing is silly.  Let
>>>> the compiler handle it and optimize the layout.
>>>
>>> Ah, but optimize it how?  There's something to be said for being able
>>> to offer the compiler a hint for whether it should optimize for time
>>> (using strict alignments for faster member access) or space (packing
>>> members more tightly while avoiding breaking anything).  Still, I'm not
>>> convinced it's worth adding as a standard language feature, particularly
>>> since on many platforms either strategy results in exactly the same
>>> layout.
>>
>> For compilers where this makes sense (typically for embedded systems),
>> there are already compiler options to do this.  The option shouldn't
>> be embedded in the source code.
>
> Unless you have one type that you want to store a gazillion instances
> of in memory (so you want to optimize space), and another with
> only a few instances each of which is accessed a gazillion times
> (so you want to optimize access time).

Which is precisely why you want a compiler option and not a pragma.  One 
makefile is a lot quicker to edit than N source files!

-- 
Ian Collins

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnlj68mdg5.fsf@nuthaus.mib.org...
> Ian Collins <ian-news@hotmail.com> writes:
>> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>>> "FredK"<fred.nospam@dec.com>  writes:
>>>
>>> Of course a differently defined #pragma could, but I doubt that it
>>> would be practical for C.
>>>
>>>> For a generic C program that isn't doing any of this, packing is silly. 
>>>> Let
>>>> the compiler handle it and optimize the layout.
>>>
>>> Ah, but optimize it how?  There's something to be said for being able
>>> to offer the compiler a hint for whether it should optimize for time
>>> (using strict alignments for faster member access) or space (packing
>>> members more tightly while avoiding breaking anything).  Still, I'm not
>>> convinced it's worth adding as a standard language feature, particularly
>>> since on many platforms either strategy results in exactly the same
>>> layout.
>>
>> For compilers where this makes sense (typically for embedded systems),
>> there are already compiler options to do this.  The option shouldn't
>> be embedded in the source code.
>
> Unless you have one type that you want to store a gazillion instances
> of in memory (so you want to optimize space), and another with
> only a few instances each of which is accessed a gazillion times
> (so you want to optimize access time).
>

The "small" systems I have contain 4-5GB of physical memory and a 64-bit 
virtual memory space (well, probably closer to 62 or 63 bits after you carve 
out OS-specific spaces).  The large ones I occasionally test on now have hit 
the terrabyte size.  I'm not sure how to express a gazillion in C :-)  but 
these days I seldom worry about memory footprint.  If I had a gazillion 
objects in memory, I probably would be more concerned with access time and 
cache misses than the size of each object.  If the size *was* a concern, I'd 
want more than a hint.  I'd want a #pragma align method to control the 
packing and alignment of just that structure exactly.

I *do* sometime worry about packing layouts especially ones that will be 
stored externally - but a packing "hint" would be useless in that case.

> On the other hand, it's not clear that it's worthwhile to clutter
> the language with too many performance hints.
>

All of the compilers I have used for the last 20 years had compiler 
optimization options for space vs speed - code size being the main target. 
I can't recall the last time I optimized for space.

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnlj68mdg5.fsf@nuthaus.mib.org...
> Ian Collins <ian-news@hotmail.com> writes:
>> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>>> "FredK"<fred.nospam@dec.com>  writes:

snip

>
> Unless you have one type that you want to store a gazillion instances
> of in memory (so you want to optimize space), and another with
> only a few instances each of which is accessed a gazillion times
> (so you want to optimize access time).
>
> On the other hand, it's not clear that it's worthwhile to clutter
> the language with too many performance hints.
>

Actually, it just occured to me that there is perhaps a structure 
optimization hint that might make sense...  one that gives the compiler free 
reign to not only pad the structure - but to reorder the structure.  The 
optimizer might be made smart enough to analyze code access to the structure 
and minimize cache misses for example.

"FredK" <fred.nospam@dec.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lntykwmguz.fsf@nuthaus.mib.org...
>> "FredK" <fred.nospam@dec.com> writes:
>>> "Keith Thompson" <kst-u@mib.org> wrote in message
[...]
>>> For a generic C program that isn't doing any of this, packing is silly. 
>>> Let
>>> the compiler handle it and optimize the layout.
>>
>> Ah, but optimize it how?  There's something to be said for being able
>> to offer the compiler a hint for whether it should optimize for time
>> (using strict alignments for faster member access) or space (packing
>> members more tightly while avoiding breaking anything).  Still, I'm not
>> convinced it's worth adding as a standard language feature, particularly
>> since on many platforms either strategy results in exactly the same
>> layout.
>
> In 1978 when memory was small and expensive, and IO was slow - you can 
> forgive people for packed layouts and stuff like RAD50 to save every bit and 
> byte.  But memory is cheap, IO is fast, I see little point in optimizing for 
> size - with perhaps specific exceptions for embedded designs - but they have 
> their own solutions and I doubt very much if they care if there is a 
> portable standard "hint" that is probably not going to do what they want 
> anyway.

Until memory is infinitely large and cheap, and I/O is infinitely fast,
there are going to be times when you want to optimize space.  There
might be a significant advantage in fitting, say, 3 billion rather than
2.5 billion records into memory.

Again, I'm not arguing that such a hint is necessarily worth
standardizing, just that it's not obviously completely useless.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnhbgwmb4b.fsf@nuthaus.mib.org...
> "FredK" <fred.nospam@dec.com> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lntykwmguz.fsf@nuthaus.mib.org...
>>> "FredK" <fred.nospam@dec.com> writes:
>>>> "Keith Thompson" <kst-u@mib.org> wrote in message


>
> Until memory is infinitely large and cheap, and I/O is infinitely fast,
> there are going to be times when you want to optimize space.  There
> might be a significant advantage in fitting, say, 3 billion rather than
> 2.5 billion records into memory.
>
> Again, I'm not arguing that such a hint is necessarily worth
> standardizing, just that it's not obviously completely useless.
>

I wouldn't trust it to a hint.  I'd turn off alignment on the structure, 
hand align it and minimize padding.  I usually pay attention to structure 
alignment anyway, even when I'm not explicitly controlling the packing.

Ian Collins <ian-news@hotmail.com> writes:
> On 10/ 9/10 01:12 PM, Keith Thompson wrote:
>> Ian Collins<ian-news@hotmail.com>  writes:
>>> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>>>> "FredK"<fred.nospam@dec.com>   writes:
>>>>
>>>> Of course a differently defined #pragma could, but I doubt that it
>>>> would be practical for C.
>>>>
>>>>> For a generic C program that isn't doing any of this, packing is silly.  Let
>>>>> the compiler handle it and optimize the layout.
>>>>
>>>> Ah, but optimize it how?  There's something to be said for being able
>>>> to offer the compiler a hint for whether it should optimize for time
>>>> (using strict alignments for faster member access) or space (packing
>>>> members more tightly while avoiding breaking anything).  Still, I'm not
>>>> convinced it's worth adding as a standard language feature, particularly
>>>> since on many platforms either strategy results in exactly the same
>>>> layout.
>>>
>>> For compilers where this makes sense (typically for embedded systems),
>>> there are already compiler options to do this.  The option shouldn't
>>> be embedded in the source code.
>>
>> Unless you have one type that you want to store a gazillion instances
>> of in memory (so you want to optimize space), and another with
>> only a few instances each of which is accessed a gazillion times
>> (so you want to optimize access time).
>
> Which is precisely why you want a compiler option and not a pragma.  One 
> makefile is a lot quicker to edit than N source files!

I'm assuming the types are used in the same program.

Here's what I have in mind:

foo.h:
    struct needs_to_be_fast {
        /* ... */;
    };

    struct needs_to_be_small {
        /* ... */;
    };

foo.c:
    /*
     * Create a few objects of type struct needs_to_be_fast and access
     * each one a bazillion times.
     */

    /*
     * Create a bazillion objects of type struct needs_to_be_small and
     * access each one just a few times. */
     */

Or maybe the types are declared in two different .h files, but
both are #included by the same .c files.

You want the hint ("Hey compiler, pack this type as small as you
reasonably can.") to apply to one type but not the other.  I don't
see how a compiler option makes this easier than a pragma.

If packing is supported, it should IMHO be an attribute of the type,
not of the compiler options used to compile it.

Or you could certainly have a compiler option that affects the
layout -- but then you need to be sure you don't mix translation units
that use the same type with and without the compiler option.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 10/8/2010 5:44 PM, FredK wrote:
> "Keith Thompson"<kst-u@mib.org>  wrote in message
> news:lnk4lso9s2.fsf@nuthaus.mib.org...
>> Michael Schumacher<misc_@gmx.de>  writes:
>>> Keith Thompson wrote:
>>>> Michael Schumacher<misc_@gmx.de>  writes:
>>>> [...]
>>>>>                                                So, while quite a
>>>>> few compilers with a considerable market share /do/ support the
>>>>> "#pragma pack" directive, many others do /not/ (or provide this
>>>>> behaviour through other means), so it's too early to consider it
>>>>> a real "standard feature".
>>>>
>>>> Agreed -- except that I wouldn't say it's "too early".  The
>>>> "#pragma pack" directive is simply non-standard.  Something like
>>>> it *might* be added to a future standard, but I know of no serious
>>>> proposals to do so.  In particular, the latest C201x draft N1494)
>>>> doesn't mention it.
>>>
>>> And I'd be as surprised as my neighbor's dog if it ever will... ;-)
>>> That's because I simply can't imagine a portable "pack" directive-
>>>
>>> Frankly&  IMNSHO, using "pack" (where it's available) is pretty much
>>> of a hack -- sure, it might come in handy when you have to deal with
>>> a given problem on a particular platform, but it's also almost /never/
>>> portable, plus it doesn't fix potential byte-sex problems, so you're
>>> probably better off writing specialized "access functions" for these
>>> purposes.  Well, that's at least /my/ experience -- YMMV... :)
>>
>> In principle, C *could* add a "#pragma pack" or similar feature whose
>> purpose is to give a hint to the compiler that it should optimize
>> layouts for space rather than speed of access.  That's what Pascal's
>> "packed record" and Ada's "pragma Pack(Type_Name)" do.
>>
>> Such a feature would not be particularly useful for imposing a specified
>> layout, and on many implementations it would probably be ignored (since
>> compilers often choose the tightest layout compatible with alignment
>> requirements anyway).  It might make be useful on platforms where
>> misaligned accesses are merely slower than aligned access.
>>
>
> Actually, it serves several purposes.
>
> 1) To be able to define a structure that is already carved in stone, for
> example a network packet format that was designed for space.  Or a legacy
> structure that is shared with legacy code.  Before RISC hardware exposed the
> inherent problems with poorly aligned data, there were compilers and
> programmers who didn't pay any attention to alignment and generated
> unaligned structure layouts.

     Two objections to this paragraph: First, as Keith says, packing
the struct is not enough to match a carved-in-stone format imposed
externally.  You still need to fret about representational issues:
How many bytes are in a `type T', how are the bits arranged, what is
the significance of this bit or that, ...?  Heck, you can't even be
sure how many bits a "byte" has (often 8, sometimes 32, even weirder
counts on older machinery).

     Second, alignment issues arose long before RISC implementations
became the vogue.  I remember dealing with them four decades ago, and
I'm morally certain I wasn't the first.

> 2) Creating structures to map hardware registers.  Usually old hardware,
> since today hardware registers tend to be at least 32-bit aligned and well
> aligned.  Nonetheless there are many old cards that were a hodge podge.   I
> seldom used this, because there can be other restrictions that make it hard
> to use.

     This is just (1), and falls to the same objections.

> 3) Making sure that the layout of a shared structure is exact - because it
> will be accessed by things not written in C or compiled by the same C
> compiler for example.  This requires the programmer to take on the
> responsibility for proper alignment.  Of course, in those cases I use a
> seperate tool that is language independent and can generate the proper
> definitions for multiple languages.

     (1) yet again.  The use of a "DDL" for generating compatible
definitions in multiple languages (and often for generating code) is
a useful technique, far more useful than hoping "#pragma magic" will
somehow solve the problems.

> For a generic C program that isn't doing any of this, packing is silly.  Let
> the compiler handle it and optimize the layout.

     Yes.  And write "marshalling" and "unmarshalling" code to mediate
between internal and external representations.  Don't kid yourself by
imagining that the compiler can be persuaded to do it for you by magic.
You can't slap "#pragma pack" onto a C program and produce portable
assembly code, no more than you can slap "#pragma Deutsch" onto a
Goethe poem and get automatic English.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message 
news:i8oh5d$bcp$1@news.eternal-september.org...
> On 10/8/2010 5:44 PM, FredK wrote:
>> "Keith Thompson"<kst-u@mib.org>  wrote in message
>> news:lnk4lso9s2.fsf@nuthaus.mib.org...
>>> Michael Schumacher<misc_@gmx.de>  writes:
>>>> Keith Thompson wrote:
>>>>> Michael Schumacher<misc_@gmx.de>  writes:
>>>>> [...]

[...]

> Don't kid yourself by
> imagining that the compiler can be persuaded to do it for you by magic.
> You can't slap "#pragma pack" onto a C program and produce portable
> assembly code, no more than you can slap "#pragma Deutsch" onto a
> Goethe poem and get automatic English.
>

I would never use such a thing.  Actually I use #pragma align, and hand lay 
out the structure myself when needed.  I have no use for a pragma that is a 
hint.  Nor is #pragma align portable (although there is no reason why it 
could not be made the standard) - but I seldom worry too much about 
portability when using C.

On 10/8/2010 8:38 PM, Ian Collins wrote:
> On 10/ 9/10 01:12 PM, Keith Thompson wrote:
>> Ian Collins<ian-news@hotmail.com> writes:
>>> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>>>> "FredK"<fred.nospam@dec.com> writes:
>>>>
>>>> Of course a differently defined #pragma could, but I doubt that it
>>>> would be practical for C.
>>>>
>>>>> For a generic C program that isn't doing any of this, packing is
>>>>> silly. Let
>>>>> the compiler handle it and optimize the layout.
>>>>
>>>> Ah, but optimize it how? There's something to be said for being able
>>>> to offer the compiler a hint for whether it should optimize for time
>>>> (using strict alignments for faster member access) or space (packing
>>>> members more tightly while avoiding breaking anything). Still, I'm not
>>>> convinced it's worth adding as a standard language feature,
>>>> particularly
>>>> since on many platforms either strategy results in exactly the same
>>>> layout.
>>>
>>> For compilers where this makes sense (typically for embedded systems),
>>> there are already compiler options to do this. The option shouldn't
>>> be embedded in the source code.
>>
>> Unless you have one type that you want to store a gazillion instances
>> of in memory (so you want to optimize space), and another with
>> only a few instances each of which is accessed a gazillion times
>> (so you want to optimize access time).
>
> Which is precisely why you want a compiler option and not a pragma. One
> makefile is a lot quicker to edit than N source files!

     How big is N in your projects, Ian?  If your program uses a
`struct S' type, in how many source files do you declare `struct S'?
If N>1 leave your programmers' license at the desk on your way out,
there's a good lad.

     (Okay: I'll allow you N==2 as a temporary stopgap under emergency
conditions and with a signed release from Buddha Himself -- but if you
try for N>=3 you are irretrievably doomed, damned, and dumbed.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 10/ 9/10 03:31 PM, Eric Sosman wrote:
> On 10/8/2010 8:38 PM, Ian Collins wrote:
>> On 10/ 9/10 01:12 PM, Keith Thompson wrote:
>>> Ian Collins<ian-news@hotmail.com> writes:
>>>> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>>>>> "FredK"<fred.nospam@dec.com> writes:
>>>>>
>>>>> Of course a differently defined #pragma could, but I doubt that it
>>>>> would be practical for C.
>>>>>
>>>>>> For a generic C program that isn't doing any of this, packing is
>>>>>> silly. Let
>>>>>> the compiler handle it and optimize the layout.
>>>>>
>>>>> Ah, but optimize it how? There's something to be said for being able
>>>>> to offer the compiler a hint for whether it should optimize for time
>>>>> (using strict alignments for faster member access) or space (packing
>>>>> members more tightly while avoiding breaking anything). Still, I'm not
>>>>> convinced it's worth adding as a standard language feature,
>>>>> particularly
>>>>> since on many platforms either strategy results in exactly the same
>>>>> layout.
>>>>
>>>> For compilers where this makes sense (typically for embedded systems),
>>>> there are already compiler options to do this. The option shouldn't
>>>> be embedded in the source code.
>>>
>>> Unless you have one type that you want to store a gazillion instances
>>> of in memory (so you want to optimize space), and another with
>>> only a few instances each of which is accessed a gazillion times
>>> (so you want to optimize access time).
>>
>> Which is precisely why you want a compiler option and not a pragma. One
>> makefile is a lot quicker to edit than N source files!
>
> How big is N in your projects, Ian? If your program uses a
> `struct S' type, in how many source files do you declare `struct S'?
> If N>1 leave your programmers' license at the desk on your way out,
> there's a good lad.

:) Point taken!

I was thinking of the more generic space/size code optimisations.

-- 
Ian Collins

On 10/8/2010 10:36 PM, Ian Collins wrote:
> On 10/ 9/10 03:31 PM, Eric Sosman wrote:
>> On 10/8/2010 8:38 PM, Ian Collins wrote:
>>> On 10/ 9/10 01:12 PM, Keith Thompson wrote:
>>>> Ian Collins<ian-news@hotmail.com> writes:
>>>>> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>>>>>> "FredK"<fred.nospam@dec.com> writes:
>>>>>>
>>>>>> Of course a differently defined #pragma could, but I doubt that it
>>>>>> would be practical for C.
>>>>>>
>>>>>>> For a generic C program that isn't doing any of this, packing is
>>>>>>> silly. Let
>>>>>>> the compiler handle it and optimize the layout.
>>>>>>
>>>>>> Ah, but optimize it how? There's something to be said for being able
>>>>>> to offer the compiler a hint for whether it should optimize for time
>>>>>> (using strict alignments for faster member access) or space (packing
>>>>>> members more tightly while avoiding breaking anything). Still, I'm
>>>>>> not
>>>>>> convinced it's worth adding as a standard language feature,
>>>>>> particularly
>>>>>> since on many platforms either strategy results in exactly the same
>>>>>> layout.
>>>>>
>>>>> For compilers where this makes sense (typically for embedded systems),
>>>>> there are already compiler options to do this. The option shouldn't
>>>>> be embedded in the source code.
>>>>
>>>> Unless you have one type that you want to store a gazillion instances
>>>> of in memory (so you want to optimize space), and another with
>>>> only a few instances each of which is accessed a gazillion times
>>>> (so you want to optimize access time).
>>>
>>> Which is precisely why you want a compiler option and not a pragma. One
>>> makefile is a lot quicker to edit than N source files!
>>
>> How big is N in your projects, Ian? If your program uses a
>> `struct S' type, in how many source files do you declare `struct S'?
>> If N>1 leave your programmers' license at the desk on your way out,
>> there's a good lad.
>
> :) Point taken!
>
> I was thinking of the more generic space/size code optimisations.

     Anecdote alert: I recall an instance where the (moral equivalent
of) #pragma pack slowed a program down by, by -- well, by I really
don't know how much, but probably a factor of some hundreds of millions.

     It was in one of a vendor's system header files, which carefully
preserved the current packing state, turned on packing, declared a few
packed structs, and restored the original state.  Except there was
this tiny typo, y'see, which meant that the original state didn't get
restored.  The upshot was that if a module #include'd the poisonous
header all its subsequent struct declarations were packed, but if it
didn't they were unpacked.  Thus, the structs declared in "mytypes.h"
were sometimes packed and sometimes not, depending on whether the
faulty header had been #include'd ...

     This, er, quirk made sharing data between separately-compiled
modules somewhat more exciting than usual ...

     My "hundreds of millions" guess is based on the amount of time I
and many others like me at lots of customer sites spent tracking down
mysterious crashes in perfectly good code, plus the time the vendor
spent investigating and developing and distributing a patch, plus the
time spent applying the patch and recompiling and retesting The World
at all those customer sites -- That's a *lot* of cumulative CPU time
and programmer time soaked up, and probably never repaid.

     (The vendor in question went out of business.  Not for this reason
alone, certainly -- but it's suggestive, don't you think?)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 10/ 9/10 02:39 PM, Eric Sosman wrote:
> On 10/8/2010 5:44 PM, FredK wrote:
>
>> For a generic C program that isn't doing any of this, packing is
>> silly. Let the compiler handle it and optimize the layout.
>
> Yes. And write "marshalling" and "unmarshalling" code to mediate
> between internal and external representations. Don't kid yourself by
> imagining that the compiler can be persuaded to do it for you by magic.
> You can't slap "#pragma pack" onto a C program and produce portable
> assembly code, no more than you can slap "#pragma Deutsch" onto a
> Goethe poem and get automatic English.

My turn!

Anecdote alert:

In a land far away and a time long ago I was working on a fairly complex 
multiple card system that was having all sorts of unpleasant and at the 
time with the tools available, unfathomable crashes.  So I suggested to 
the bosses running the problematic card's software on my workstation so 
I could use the host debugger.  "Great, go for it" they said, so I did.

But the target was 68K with packed structures and the workstation a new 
fangled SPARC box, which didn't take kindly to misaligned access.  I 
could compile and run the code, but it ran like a three legged dog with 
every unnatural access trapping to call memcpy.

So thought, um how about using this new C++ stuff I'd been tinkering 
with?  I could write C++ versions of the structs that did the packing 
and unpacking and keep the original source.  "Great, go for it" they 
said, so I did.

Thus "#pragma pack" was responsible for my decent down the slippery slope..

-- 
Ian Collins

Keith Thompson <kst-u@mib.org> writes:

> In principle, C *could* add a "#pragma pack" or similar feature whose
> purpose is to give a hint to the compiler that it should optimize
> layouts for space rather than speed of access.  That's what Pascal's
> "packed record" and Ada's "pragma Pack(Type_Name)" do.

>
> Such a feature would not be particularly useful for imposing a specified
> layout, and on many implementations it would probably be ignored (since
> compilers often choose the tightest layout compatible with alignment
> requirements anyway).  It might make be useful on platforms where
> misaligned accesses are merely slower than aligned access.

I'd like C to offer a feature (almost certainly not by a #pragma as it
should be available structure-by-structure) to say "I will never care
about the order of things in this structure, feel free to re-organise
them).  Sometimes you have a mix of pointers and booleans in a structure
and the self-documenting order makes it terribly inefficient for space.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

Eric Sosman wrote:

> On 10/8/2010 5:44 PM, FredK wrote:
>> "Keith Thompson"<kst-u@mib.org>  wrote in message
>> news:lnk4lso9s2.fsf@nuthaus.mib.org...
>>> Michael Schumacher<misc_@gmx.de>  writes:
>>>>
>>>> Frankly&  IMNSHO, using "pack" (where it's available) is pretty much
>>>> of a hack -- sure, it might come in handy when you have to deal with
>>>> a given problem on a particular platform, but it's also almost /never/
>>>> portable, plus it doesn't fix potential byte-sex problems, so you're
>>>> probably better off writing specialized "access functions" for these
>>>> purposes.  Well, that's at least /my/ experience -- YMMV... :)
>>>
>>> In principle, C *could* add a "#pragma pack" or similar feature whose
>>> purpose is to give a hint to the compiler that it should optimize
>>> layouts for space rather than speed of access.  That's what Pascal's
>>> "packed record" and Ada's "pragma Pack(Type_Name)" do.

Sure, but I think most people using this pragma expect it to tell the
compiler to omit any alignments between structure members, so they can
easily handle, e.g., the records of external data representations such
as MPEG or DooM WAD files.  Needless to say, this is neither portable
nor efficient (see below), which is why I call using it a "hack".

>> For a generic C program that isn't doing any of this, packing is silly. 
>> Let the compiler handle it and optimize the layout.
> 
>      Yes.  And write "marshalling" and "unmarshalling" code to mediate
> between internal and external representations.

That's exactly my point (well, I called it "access functions", your
term "(un)marshalling code" is certainly better, but I'm sure we both
mean the same mechanism -- it's just the language barrier).  "#pragma
pack" might actually help you when dealing with file headers/records
as mentioned above (as well as hardware registers) enforcing a certain
layout, but not in a portable way, and it doesn't address the byte-sex
problem.  For instance, ELF headers of objects/executables/core files
can be encoded litte- or big-endian.  "#pragma pack" won't help you in
these cases, so the only portable and efficient way to handle them is
to write (to use your fine wording) "'marshalling' and 'unmarshalling'
code to mediate between internal and external representations". 

> Don't kid yourself by
> imagining that the compiler can be persuaded to do it for you by magic.
> You can't slap "#pragma pack" onto a C program and produce portable
> assembly code, no more than you can slap "#pragma Deutsch" onto a
> Goethe poem and get automatic English.

Yep! :-)


mike

Ian Collins wrote:

> On 10/ 9/10 11:58 AM, Keith Thompson wrote:
>> "FredK"<fred.nospam@dec.com>  writes:
>>
>> Of course a differently defined #pragma could, but I doubt that it
>> would be practical for C.
>>
>>> For a generic C program that isn't doing any of this, packing is silly. 
>>> Let the compiler handle it and optimize the layout.
>>
>> Ah, but optimize it how?  There's something to be said for being able
>> to offer the compiler a hint for whether it should optimize for time
>> (using strict alignments for faster member access) or space (packing
>> members more tightly while avoiding breaking anything).  Still, I'm not
>> convinced it's worth adding as a standard language feature, particularly
>> since on many platforms either strategy results in exactly the same
>> layout.
> 
> For compilers where this makes sense (typically for embedded systems),
> there are already compiler options to do this.  The option shouldn't be
> embedded in the source code.

Unfortunately, it often is, especially in older code that was written
for a different environment (hardware, compiler, ...).  In many cases
(particularly in the realm of safety-critical applications) this code
has been inspected by technical authorities and proven to be correct
(horribly expensive!), which means you're allowed to use it in your
software w/out the need to have it approved again -- but /only/ if it
is re-used "verbatimly", with no changes whatsoever.

When these companies are switching to new, "incompatible" hardware
and likewise incompatible tools, they're rather willing to spend a
fortune for the tool providers to adopt to "their" standard, than to
change their code and having to go through the approval process all
over (which would take multipe fortunes -- and much, much longer).

In such cases, "#pragma pack" will rarely be the biggest problem; the
more, um, "interesting" things are 16-bit integers, "memory models"
(think "near"/"large"/"huge") and all sorts of "language extensions"
("__interrupt", register assignments for parameters/variables, etc.)
which were used in the original "C" source code.  Oh, and never, let
me repeat: /never/ ever try to convince the owners of such code that
having had it approved in this form and shape was a "very bad thing"
in the first place... ;-)


mike

On 10/7/2010 3:10 PM, Michael Schumacher wrote:
> John Smith wrote:

>> Sagt man "kom pee' luh" for compiler?
>
> Not really; it's usually the english word "compiler".  Long time
> ago (70s/80s) one could also (rarely!) read the word "Kompiler"
> in certain publications, but I guess the pronouncation was still
> english; it didn't prevail and never made it to the mainstream.
> So, it's either "Compiler" (pronounced as in english, but written
> with a capital "C", as it's a noun), or "Übersetzer", the german
> word for "translator".  But we mainly say "Compiler" when we're
> talking about computer languages.  However, we call the /process/
> of translating a program written in one computer language to some
> other computer language (incl. assembler or actual machine code)
> "Kompilieren" ("'com'pee'lee-ren" -- the apostrophes denote where
> to stress the parts of the word; "ren" just as in "renegade").
>
>> The first C texts that I read in German used the word "Kompilator."
>
> I've never actually heard that word, but it sounds funny!  To the
> typical German it wouldn'n make any sense, but it rhymes to, e.g.,
> "Ventilator" (fan) -- which would be especially confusing if you'd
> say "Ich habe gerade den Kompilator angeworfen" ("I've just started
> the kompilator") -- but nothing really happens...  ;-)
>
>> I very much enjoy the Janich and Schreiner translation of K&R2.
>> One thing that's different about the "reservierte Worte," is that
>> they're all in a different language: english.
>
> Yes, they indeed did a really good job!  But given "Axel T's" Unix/C
> experience and being a german professor in the U.S., this is not too
> much of a surprise, or is it?  :-)

Axel T.?
> |Oh, BTW: as this is both, about C and the German language w/ repect
> to C, I've omitted the F2-header; please feel free to adjust it for
> f'ups, if any.  To further discuss the "german aspects" of this
> matter, I'd suggest posting a F2/XP to "de.etc.sprache.misc".]

[OP has also responded as John Smith in this thread]

I'm switching nyms without really trying.  I'm writing on my windows 
partition as opposed to the partition I develop on.  My first CS mentor 
was Leroy Wentz, who lived in Germany as he programmed for satellites. 
He was my employer at Basic Software Services in '82 while I was still a 
young teen.

We corresponded while I was on an lds mission to germany from '85-'87, 
and I did not touch a computer once during that time.  Later, to keep my 
language skills sharp, I read technical texts, and so now that there's a 
lot of water under the bridge, I speak with that american potato in my 
mouth, but I can communicate about a much broader range of material.

I read this week that your word for declaration is "Vereinbarung," which 
I might have called, in english, "agreement."
-- 
Uno

Uno wrote:

> On 10/7/2010 3:10 PM, Michael Schumacher wrote:
>> John Smith wrote:

>>> [...]
>>> I very much enjoy the Janich and Schreiner translation of K&R2.
>>> One thing that's different about the "reservierte Worte," is that
>>> they're all in a different language: english.
>>
>> Yes, they indeed did a really good job!  But given "Axel T's" Unix/C
>> experience and being a german professor in the U.S., this is not too
>> much of a surprise, or is it?  :-)
> 
> Axel T.?

Prof. Axel-Tobias Schreiner (see <http://www.cs.rit.edu/~ats>).

>> |Oh, BTW: as this is both, about C and the German language w/ repect
>> to C, I've omitted the F2-header; please feel free to adjust it for
>> f'ups, if any.  To further discuss the "german aspects" of this
>> matter, I'd suggest posting a F2/XP to "de.etc.sprache.misc".]
> 
> [OP has also responded as John Smith in this thread]
> 
> I'm switching nyms without really trying.

What does "nyms" mean (I guess it's short for "pseudonyms")?

> [...]
> I read this week that your word for declaration is "Vereinbarung,"
> which I might have called, in english, "agreement."

Which, in this particular context, would even make sense: declarations
in header files make sure that separate modules "agree" on the layout
and names of types, variables and functions.

However, "declaration" in German does also mean "Erklärung", which in
English means "explanation".  Not in the sense that someone has asked
a question and now gets an answer, but in the sense of a "declaration
of rights" or a "curstoms declaration".  That's the actual meaning of
"Vereinbarung", "Erklärung" and "Deklararation" as the translation of
the English word "declaration".  HTH.


Cheers,
mike

On 10/8/2010 10:53 AM, Nick Keighley wrote:
> On 7 Oct, 23:50, Keith Thompson<ks...@mib.org>  wrote:
[...]
>> Agreed -- except that I wouldn't say it's "too early".  The
>> "#pragma pack" directive is simply non-standard.  Something like
>> it *might* be added to a future standard, but I know of no serious
>> proposals to do so.  In particular, the latest C201x draft N1494)
>> doesn't mention it.
>
> isn't #pragma pack hard (or very expensive) to implement on some
> architectures?

As I recall, the IBM RS/6000 RISC platform would cause a hardware fault when 
trying a misaligned memory access, which was trapped by the O/S kernel, and 
the operation handled via software.  I guess this qualifies as "very 
expensive".  (Though, admittedly, it's very "easy" to implement as far as 
user code is concerned.)

-- 
Kenneth Brody

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 10/8/2010 10:53 AM, Nick Keighley wrote:
>> On 7 Oct, 23:50, Keith Thompson<ks...@mib.org>  wrote:
> [...]
>>> Agreed -- except that I wouldn't say it's "too early".  The
>>> "#pragma pack" directive is simply non-standard.  Something like
>>> it *might* be added to a future standard, but I know of no serious
>>> proposals to do so.  In particular, the latest C201x draft N1494)
>>> doesn't mention it.
>>
>> isn't #pragma pack hard (or very expensive) to implement on some
>> architectures?
>
> As I recall, the IBM RS/6000 RISC platform would cause a hardware fault when 
> trying a misaligned memory access, which was trapped by the O/S kernel, and 
> the operation handled via software.  I guess this qualifies as "very 
> expensive".  (Though, admittedly, it's very "easy" to implement as far as 
> user code is concerned.)

My recollection (which could well be mistaken) is that a misaligned
access would quietly access the corresponding aligned address.
For example, attempting to read a 4-byte word from address 0x12340001
would instead read a 4-byte word starting at address 0x12340000;
the low-order bit(s) would be ignored.

Perhaps different versions of the RS/6000 did different things.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Nick Keighley wrote:

> isn't #pragma pack hard (or very expensive) to implement on some
> architectures?

The main problem is to define what "pack" should really achieve:
if all you expect it to do is to tell the compiler to use the
"tightest" layout for a struct/union that can be handled on a
given architecture (possibly even rearranging its members), then
it's pretty easy to implement.  This also means that this is not
portable, and you might even lose control over the layout, so you
can only adress the struct/union members by name -- of course, that
is the "clean" way, so most people will be happy with that solution.

Unfortunately, all of this changes when a particular layout is used
for a file format (or some hardware "register file" description),
where you must exactly specify the length and bit/byte ordering of
the individual members, and also in their correct order.

In such cases, "pack" won't buy you anything (but trouble): if the
format is little-endian, but your target CPU uses big-endian, even
the correct member sizes wouldn't help you, let alone the "random"
order of the members as was chosen by the "original" compiler used
by the format's author.

Implementing "#pragma pack" just to override alignment restrictions
for a given architecture is plain silly -- or, in your words, "very
expensive": maybe a CPU can transparently handle misaligned memory
accesses at the cost of additional cycles, or it simply traps, so
either a program will crash or be shutdown by the OS, or a special
(software!) trap handler will be invoked that needs to analyze the
faulting instruction and use costly "magic" to resolve the conflict
in a transparent manner.  There's also another possibility: there
are [CM]PUs that do require a certain layout (say, even addresses),
but they won't trap in case this restriction is being violated, and
instead produce incorrect values/results, leading to "funny runtime
experiences" that are even /more/ fun to debug...

C (and most other standardized programming languages, FWIW) fall
semantically short when it comes to particular memory layouts --
be it for data, code, or even code execution paths.  That's for the
sake of portability across platforms.

Perfectly okay for portable /applications/ -- but it fails miserably
when it comes to the realm of embedded and operating systems.  This
is one of the big reasons why the GNU tools are so popular in these
areas: they provide many useful additions such as inline assembler,
attributes that allow one to specify aligment, section and lots of
other things for types, variables and functions, and even link-time
optimizations (plus much more -- including "#pragma pack").

But I'd never expect these additions, as useful as they are, to ever
become part of the official ISO C standard, at least not all of them.
To me, that's actually not much of a problem, because the GNU tools
can be used to write both, plain standard programs, as well as stuff
that is highly optimized for a particular platform -- albeit /still/
being fairly portable, as GCC itself is highly portable, so chances
are that you can easily move the hardware dependent parts to any new
architecture with moderate efforts -- if you're coding carefully!).

Nonetheless, I'll still stick to my words mentioned earlier in this
thread: if you need to adopt to a particular layout, you're better
off writing specialized "access" or "conversion" functions to switch
between internal and external representations (which can be generic
or optimized for a given platform), 'cos "#pragma pack" is certainly
never a clever control to be used in portable code.  Not even if its
actual effects were to be written in ISOfied stones... :)


Cheers,
mike

Default User wrote:
> "John Smith" <john@example.invalid> wrote in message 
> news:0pmdnXeOEK5ftDDRnZ2dnUVZ5q-dnZ2d@giganews.com...
>> Default User wrote:
>>> "Seebs" <usenet-nospam@seebs.net> wrote in message 
>>> news:slrniapqr2.1s4n.usenet-nospam@guild.seebs.net...
>>>> On 2010-10-06, Mr. Buffoon <Buffoon@googlemail.com> wrote:
>>>>> Almost any kompiler has #pragma pack(x);
>>>>> so sonsider it a standard-feature!
>>>> You shouldn't consider something standard because
>>>> several compilers have it, less still because some guy on the Internet 
>>>> tells
>>>> you that "almost any kompiler" has it.
>>>
>>> To be fair, he did request that you "sonsider" it.
> 
>> Let's hope for 610.  We'll C.
> 
> Piece of cake.

I listen to cake radio on pandora.
-- 
Uno

Michael Schumacher wrote:
> Mr. Buffoon wrote:
> 
>> Am 08.10.2010 00:10, schrieb Michael Schumacher:
>>
>>> This has changed some time ago, since the new keyword "_Pragma"
>>> has been introduced (so you can now write #defines producing
>>> _Pragmas), but still, "#pragma pack" isn't part of the official
>>> C standard (please correct me if I'm wrong).  So, while quite a
>>> few compilers with a considerable market share /do/ support the
>>> "#pragma pack" directive, many others do /not/ (or provide this
>>> behaviour through other means), so it's too early to consider it
>>> a real "standard feature".
>> Falsch, setzen, sechs!!!
> 
> Du möchtest etwas Sinnvolles zu diesem Thema beitragen?  Nur zu...!

Sechs mag nicht gerade sinnvoll sein aber traegt zu meinem Sinn ein. 
Sechs kann also zu vielerlei fuehren, darunter, semen, nay, sieben. 
(Und habt ihr bei Euch ein nicht-Staebliches Siemens?)

Hat man sechs und sieben, kann man vernuenftig mit zweiundvierzig 
zurueckkehren.

Gruss aus den Staaten,
-- 
Uno