Rocksolid Light

groups  faq  privacy  How to post  login

Message-ID:  

Q: What do you say to a New Yorker with a job? A: Big Mac, fries and a Coke, please!


rocksolid / de.comp.lang.c / Re: Padding von Strukturen

SubjectAuthor
* Padding von StrukturenMichael Bäuerle
+- Re: Padding von StrukturenClaus Reibenstein
+* Re: Padding von StrukturenPeter J. Holzer
|`* Re: Padding von StrukturenMichael Bäuerle
| `- Re: Padding von StrukturenStefan Reuther
+* Re: Padding von StrukturenStefan Reuther
|`* Re: Padding von StrukturenPeter J. Holzer
| `- Re: Padding von StrukturenMichael Bäuerle
+- Re: Padding von StrukturenBonita Montero
+* Re: Padding von StrukturenRainer Weikusat
|`- Re: Padding von StrukturenBonita Montero
`* Re: Padding von StrukturenHelmut Schellong
 `* Re: Padding von StrukturenBonita Montero
  `* Re: Padding von StrukturenHelmut Schellong
   `* Re: Padding von StrukturenBonita Montero
    `- Re: Padding von StrukturenHelmut Schellong

1
Subject: Padding von Strukturen
From: Michael Bäuerle
Newsgroups: de.comp.lang.c
Date: Fri, 26 Jan 2024 16:51 UTC
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: michael....@stz-e.de (Michael Bäuerle)
Newsgroups: de.comp.lang.c
Subject: Padding von Strukturen
Date: Fri, 26 Jan 2024 17:51:08 +0100 (CET)
Lines: 60
Message-ID: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
Reply-To: Michael Bäuerle <michael.baeuerle@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net KesCtZ0g2DgUMS+GRQ39XgzvqQkBpK0aWRqpG8ekngbpNZvm6p
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:mtst8Twk3imU6CqtGyFJinRJucw= sha256:xz3nVY9IUS67+/AWxwqvWSbfHEljPoete3Axbj3LDmc= sha1:AkSCyo5e5x7oCJH9k5k8Tiifnvs= sha256:8+v546OKv8wf39C9rWG0/iQhcZSa+rjgB26MiiLh9w8=
Injection-Date: Fri, 26 Jan 2024 16:51:08 -0000
User-Agent: flnews/1.2.1pre6 (for NetBSD)
View all headers

Ich hatte kürzlich eine Diskussion zum Padding in Strukturen und
deren Größe. Es ging dabei nicht um das Alignment der Elemente in der
Struktur, sondern um das Padding am Ende, ob /sizeof/ dieses mitrechnet
oder nicht und ob es (für das Aligment in einem Array aus solchen
Strukturen) vorhanden sein muss oder nicht.

Im Kern ging es um die Frage, ob es in C90 bzw. C99 *portabel* möglich
ist die Größe einer Struktur mit der Anzahl der Elementen eines Arrays
zu multiplizieren, um den Speicher für ein solches Array z.B. mit:

size_t n = 3;
struct foo *p = malloc(n * sizeof (struct foo));

anzufordern.

Die Frage, ob sizeof das Padding am Ende einer Struktur mitrechnet,
beantwortet die Norm eindeutig. Zitat aus dem C99 draft N1256:
|
| 6.5.3.4 The sizeof operator
|
| 3 [...]
| When applied to an operand that has array type, the result is the
| total number of bytes in the array. When applied to an operand that
| has structure or union type, the result is the total number of bytes
| in such an object, including internal and trailing padding.
^^^^^^^^^ ^^^^^^^^^^^^^^^^

Die Frage, ob dieses Padding vorhanden sein *muss* (passend für das
nötige Alignment der Zielmaschine), blieb aber offen.
Zitat aus dem C99 draft N1256:
|
| 6.7.2.1 Structure and union specifiers
|
| [...]
| 12 Each non-bit-field member of a structure or union object is
| aligned in an implementation-defined manner appropriate to its
| type.
| [...]
| 15 There may be unnamed padding at the end of a structure or union.

Das würde dem Compiler auch erlauben das Padding am Ende der Struktur
wegzulassen, so dass sizeof es nicht mitrechnet, solange er z.B.:

struct foo bar[3];

mit separatem Padding korrekt anordnen kann und Zugriffe mit bar[n]
diese Anordnung berücksichtigen. Auch für Zeiger + Integer könnte das
so funktionieren. Zitat aus dem C99 draft N1256:
|
| 6.5.6 Additive operators
|
| 8 [...] When an expression that has integer type is added to or
| subtracted from a pointer, [...]
| If the pointer operand points to an element of an array object, and
| the array is large enough, the result points to an element offset from
| the original element such that the difference of the subscripts of the
| resulting and original array elements equals the integer expression.

Da steht nicht, dass der Offset ein Vielfaches der Größe der Elemente
(entsprechend dem was sizeof liefert) sein muss.

Subject: Re: Padding von Strukturen
From: Claus Reibenstein
Newsgroups: de.comp.lang.c
Date: Fri, 26 Jan 2024 17:41 UTC
References: 1
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: creib...@gmail.com (Claus Reibenstein)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Fri, 26 Jan 2024 18:41:14 +0100
Lines: 15
Message-ID: <l1i95qFlb77U1@mid.individual.net>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net +LIfMhfpRU7HoQ9RKragxg7KP/GU2ootFdoZi993ZGuVJgWtc=
Cancel-Lock: sha1:oRguDKoyQaHUBY+IfL//lE/nIoc= sha256:d163/oQinXugthJX73a31iJ8ah6B2Srk+s1GTnOUSYU=
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
SeaMonkey/2.53.18.1
In-Reply-To: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
View all headers

Michael Bäuerle schrieb am 26.01.2024 um 17:51:

> Ich hatte kürzlich eine Diskussion zum Padding in Strukturen und
> deren Größe. Es ging dabei nicht um das Alignment der Elemente in der
> Struktur, sondern um das Padding am Ende, ob /sizeof/ dieses mitrechnet
> oder nicht und ob es (für das Aligment in einem Array aus solchen
> Strukturen) vorhanden sein muss oder nicht.

Ja, das wird mitgerechnet, und das muss auch vorhanden sein. Das steht
sicher an irgendeiner Stelle im Standard drin (habe leider keinen zur Hand).

Deine weiteren Argumente erübrigen sich damit.

Gruß
Claus

Subject: Re: Padding von Strukturen
From: Peter J. Holzer
Newsgroups: de.comp.lang.c
Organization: LUGA
Date: Fri, 26 Jan 2024 18:36 UTC
References: 1
Path: i2pn2.org!i2pn.org!news.chmurka.net!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!tahina.priv.at!news.luga.at!.POSTED.212.17.106.130!not-for-mail
From: hjp-usen...@hjp.at (Peter J. Holzer)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Fri, 26 Jan 2024 19:36:21 +0100
Organization: LUGA
Message-ID: <slrnur7ut6.1vogh.hjp-usenet4@trintignant.hjp.at>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Info: vinge.luga.at; posting-host="212.17.106.130";
logging-data="23888"; mail-complaints-to="usenet@vinge.luga.at"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:QhZosbHcthLLw2Q6WbEM9/5Cpdc=
View all headers

On 2024-01-26 16:51, Michael Bäuerle <michael.baeuerle@stz-e.de> wrote:
> Ich hatte kürzlich eine Diskussion zum Padding in Strukturen und
> deren Größe. Es ging dabei nicht um das Alignment der Elemente in der
> Struktur, sondern um das Padding am Ende, ob /sizeof/ dieses mitrechnet
> oder nicht und ob es (für das Aligment in einem Array aus solchen
> Strukturen) vorhanden sein muss oder nicht.
>
> Im Kern ging es um die Frage, ob es in C90 bzw. C99 *portabel* möglich
> ist die Größe einer Struktur mit der Anzahl der Elementen eines Arrays
> zu multiplizieren, um den Speicher für ein solches Array z.B. mit:
>
> size_t n = 3;
> struct foo *p = malloc(n * sizeof (struct foo));
>
> anzufordern.

Portabel: Ja, auf jeden Fall. Jeder Kompiler, bei dem das nicht
funktionieren würde, wäre ein Kandidat für den Darwin-Award.

Standard-konform: Da bin ich mir nur zu 99.9% sicher ;-). Gerade diese
"Selbstverständlichkeiten" stehen oft nirgends explizit im Standard,
sondern man muss mehrere Textstellen hernehmen und zeigen, dass
mindestens eine davon verletzt wäre, wenn die Selbstverständlichkeit
nicht gilt. Es gibt also eine geringe Wahrscheinlichkeit, dass eine
Implementation, in der das nicht gilt, zwar unbrauchbar, aber
standardkonform wäre. (Das ist aber auch nichts neues: Ich glaube kurz
nach dem Erscheinen von C89 hat jemand gezeigt, dass ein ein Compiler,
der nur ein einziges Programm übersetzen kann, standardkonform ist).

> Die Frage, ob sizeof das Padding am Ende einer Struktur mitrechnet,
> beantwortet die Norm eindeutig. Zitat aus dem C99 draft N1256:
>|
>| 6.5.3.4 The sizeof operator
>|
>| 3 [...]
>| When applied to an operand that has array type, the result is the
>| total number of bytes in the array. When applied to an operand that
>| has structure or union type, the result is the total number of bytes
>| in such an object, including internal and trailing padding.
> ^^^^^^^^^ ^^^^^^^^^^^^^^^^
>
> Die Frage, ob dieses Padding vorhanden sein *muss* (passend für das
> nötige Alignment der Zielmaschine), blieb aber offen.

Das kommt jetzt darauf an, was Du mit "muss" und "passend" meinst.

Prinzipiell könnte der Compiler immer Code erzeugen, der auf jedes Byte
einzeln zugreift, und hätte dann keine Alignment-Requirements. Das wäre
aber sehr ineffizient und für manche (hardware-nahen) Anwendungen könnte
man ihn gar nicht verwenden. Oder er könnte z.B. bei der x86-Architektur
(bei der unaligned Zugriffe von der Hardware erledigt werden und daher
nur ein bisschen langsamer sind) auf Alignment verzichten.

> Zitat aus dem C99 draft N1256:
>|
>| 6.7.2.1 Structure and union specifiers
>|
>| [...]
>| 12 Each non-bit-field member of a structure or union object is
>| aligned in an implementation-defined manner appropriate to its
>| type.
>| [...]
>| 15 There may be unnamed padding at the end of a structure or union.
>
> Das würde dem Compiler auch erlauben das Padding am Ende der Struktur
> wegzulassen, so dass sizeof es nicht mitrechnet, solange er z.B.:
>
> struct foo bar[3];
>
> mit separatem Padding korrekt anordnen kann und Zugriffe mit bar[n]
> diese Anordnung berücksichtigen.

Das ist aber genau die Situation, in der trailing padding benötigt wird.
Für ein einzelnes struct ist es nicht notwendig, da der Compiler keinen
Grund hat, auf dieses Padding zuzugreifen. Aber in einem array of struct
müssen alle Bestandteile richtig aligned sein. Wenn Du also z.B.

struct foo {
int i;
char c;
}

hast und ein int ein alignment von 4 benötigt, dann kann bar nicht so
aussehen:

+0: bar[0].i
+4: bar[0].c
+5: bar[1].i
+9: bar[1].c
+10: bar[2].i
+14: bar[2].c

Denn dann würde man auf bar[1].i und bar[2].i einen bus error bekommen
(oder zumindest würde der Zugriff länger dauern).
Das verhindert man, indem man die Struct auf ein Vielfaches des
Alignments des striktesten Bestandteils verlängert:

+0: bar[0].i
+4: bar[0].c
+5: bar[0]./* anonymous padding */
+8: bar[1].i
+12: bar[1].c
+13: bar[0]./* anonymous padding */
+16: bar[2].i
+20: bar[2].c
+21: bar[0]./* anonymous padding */

> Auch für Zeiger + Integer könnte das so funktionieren. Zitat aus dem
> C99 draft N1256:
>|
>| 6.5.6 Additive operators
>|
>| 8 [...] When an expression that has integer type is added to or
>| subtracted from a pointer, [...]
>| If the pointer operand points to an element of an array object, and
>| the array is large enough, the result points to an element offset from
>| the original element such that the difference of the subscripts of the
>| resulting and original array elements equals the integer expression.
>
> Da steht nicht, dass der Offset ein Vielfaches der Größe der Elemente
> (entsprechend dem was sizeof liefert) sein muss.

"offset" ist hier nach meinem Textverständnis auch kein Substantiv
sondern ein Partizip Perfekt.

hp

Subject: Re: Padding von Strukturen
From: Stefan Reuther
Newsgroups: de.comp.lang.c
Date: Sat, 27 Jan 2024 10:25 UTC
References: 1
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: stefan.n...@arcor.de (Stefan Reuther)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Sat, 27 Jan 2024 11:25:52 +0100
Lines: 32
Message-ID: <up2p80.50o.1@stefan.msgid.phost.de>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net h+Rr3PCv+/KawTGJErZacggQ6H0fWTClRv+eOX01o20WdQ4C+a
Cancel-Lock: sha1:trkP/41ZnV5F30MwCVZe4caVK0E= sha256:ei2xUvvM2vZZ+v//p+uiMHYPpWq1V9u/HzaUMnqu+4w=
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
Thunderbird/68.12.1 Hamster/2.1.0.1538
In-Reply-To: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
View all headers

Am 26.01.2024 um 17:51 schrieb Michael Bäuerle:
> Ich hatte kürzlich eine Diskussion zum Padding in Strukturen und
> deren Größe. Es ging dabei nicht um das Alignment der Elemente in der
> Struktur, sondern um das Padding am Ende, ob /sizeof/ dieses mitrechnet
> oder nicht und ob es (für das Aligment in einem Array aus solchen
> Strukturen) vorhanden sein muss oder nicht.
[...]
> Das würde dem Compiler auch erlauben das Padding am Ende der Struktur
> wegzulassen, so dass sizeof es nicht mitrechnet, solange er z.B.:
>
> struct foo bar[3];
>
> mit separatem Padding korrekt anordnen kann und Zugriffe mit bar[n]
> diese Anordnung berücksichtigen.

Ich finde ebenfalls auf die Schnelle keine explizite Aussage "ja, muss
so sein".

Allerdings gibt es dieses Beispiel in n1548 (C11) 6.5.3.4:

# EXAMPLE 2
# Another use of the sizeof operator is to compute the number of
# elements in an array:
# sizeof array / sizeof array[0]

Ein Beispiel ist zwar nicht normativ, deutet aber schon an, dass das so
gemeint ist.

`sizeof array[0]` wäre hier `sizeof(struct_type)`.

Stefan

Subject: Re: Padding von Strukturen
From: Peter J. Holzer
Newsgroups: de.comp.lang.c
Organization: LUGA
Date: Sat, 27 Jan 2024 11:21 UTC
References: 1 2
Path: i2pn2.org!rocksolid2!news.neodome.net!weretis.net!feeder8.news.weretis.net!newsfeed.xs3.de!tahina.priv.at!news.luga.at!.POSTED.212.17.106.130!not-for-mail
From: hjp-usen...@hjp.at (Peter J. Holzer)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Sat, 27 Jan 2024 12:21:21 +0100
Organization: LUGA
Message-ID: <slrnur9ppk.23re3.hjp-usenet4@trintignant.hjp.at>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
<up2p80.50o.1@stefan.msgid.phost.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Info: vinge.luga.at; posting-host="212.17.106.130";
logging-data="22086"; mail-complaints-to="usenet@vinge.luga.at"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:GisTNoMQYM8JV6XoPtJr3oQCNh8=
View all headers

On 2024-01-27 10:25, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 26.01.2024 um 17:51 schrieb Michael Bäuerle:
>> Ich hatte kürzlich eine Diskussion zum Padding in Strukturen und
>> deren Größe. Es ging dabei nicht um das Alignment der Elemente in der
>> Struktur, sondern um das Padding am Ende, ob /sizeof/ dieses mitrechnet
>> oder nicht und ob es (für das Aligment in einem Array aus solchen
>> Strukturen) vorhanden sein muss oder nicht.
> [...]
>> Das würde dem Compiler auch erlauben das Padding am Ende der Struktur
>> wegzulassen, so dass sizeof es nicht mitrechnet, solange er z.B.:
>>
>> struct foo bar[3];
>>
>> mit separatem Padding korrekt anordnen kann und Zugriffe mit bar[n]
>> diese Anordnung berücksichtigen.
>
> Ich finde ebenfalls auf die Schnelle keine explizite Aussage "ja, muss
> so sein".

Geht mir ebenso.

> Allerdings gibt es dieses Beispiel in n1548 (C11) 6.5.3.4:
>
> # EXAMPLE 2
> # Another use of the sizeof operator is to compute the number of
> # elements in an array:
> # sizeof array / sizeof array[0]
>
> Ein Beispiel ist zwar nicht normativ, deutet aber schon an, dass das so
> gemeint ist.

Ja, das habe ich auch gefunden. Zusätzlich:

Kapitel 6.2.5, Absatz 20 beschreibt Arrays als "contiguously allocated".
Leider fallen mir zwei mögliche Interpretationen davon ein, von denen
nur eine Padding zwischen den Members ausschließt. Ist also auch nicht
ganz eindeutig.

Der Standard erlaubt Padding explizit für Integer-Typen, Structs und
Unions und definiert das Verhalten. Padding innerhalb eines Arrays wird
soweit ich sehe nirgends erwähnt. Das kann man jetzt auch wieder auf
zwei Arten auslegen ("Ist offensichtlich nicht vorgesehen, sonst stünde
es da" oder "Ist nicht verboten, daher ist es erlaubt").

Die Rationale zu C89 schreibt auf S. 51:

| * if necessary, a hole is placed on the end to make the structure big
| enough to pack tightly into arrays and maintain proper alignment.

Das ist natürlich auch nicht normativ.

Insgesamt würde ich sagen, dass die Intention des Standards klar ist,
auch wenn der normative Text nicht eindeutig ist.

hp

Subject: Re: Padding von Strukturen
From: Bonita Montero
Newsgroups: de.comp.lang.c
Organization: A noiseless patient Spider
Date: Sun, 28 Jan 2024 14:45 UTC
References: 1
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Sun, 28 Jan 2024 15:45:29 +0100
Organization: A noiseless patient Spider
Lines: 3
Message-ID: <up5pa8$3v5ga$1@raubtier-asyl.eternal-september.org>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 28 Jan 2024 14:45:29 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="65968ff335b22d031a9b2814ce3faa7b";
logging-data="4167178"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/tSWQ/bGXtDamSb4jKxPmg1UMVWiY0syk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:8ZHY/x0ZodKAJft5WSsRoO6CBXQ=
In-Reply-To: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
Content-Language: de-DE
View all headers

Wird wohl keinen Compiler geben der es wagt, das anders
handzuhaben, auch wenn der Standard das nicht vorsähe.

Subject: Re: Padding von Strukturen
From: Michael Bäuerle
Newsgroups: de.comp.lang.c
Date: Mon, 29 Jan 2024 13:18 UTC
References: 1 2
Path: i2pn2.org!rocksolid2!news.neodome.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: michael....@stz-e.de (Michael Bäuerle)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Mon, 29 Jan 2024 14:18:35 +0100 (CET)
Lines: 63
Message-ID: <AABlt6WrK-wAAAI9.A3.flnews@WStation5.stz-e.de>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de> <slrnur7ut6.1vogh.hjp-usenet4@trintignant.hjp.at>
Reply-To: Michael Bäuerle <michael.baeuerle@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net osf2QYDBF1eW3a5wroeS9AnKGAxNQ8PZCr6svAMc7fjJvFWsvE
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:ueI8zRlbqlJvlPBpIAa+bRjgZaM= sha256:aorGm66EXOPr/x45SkQzAZZ0ik/f0tXliE3Z1mf31Yg= sha1:aDTCWWteJT16MyLRMv7//3hPt7E= sha256:MHXJeMB+b81xaDad/cCKAZYHHpWQ5LFsOPmEvg+sCSE=
Injection-Date: Mon, 29 Jan 2024 13:18:35 -0000
User-Agent: flnews/1.2.1pre6 (for NetBSD)
View all headers

Peter J. Holzer wrote:
> On 2024-01-26 16:51, Michael Bäuerle <michael.baeuerle@stz-e.de> wrote:
> >
> > [...]
> > Die Frage, ob sizeof das Padding am Ende einer Struktur mitrechnet,
> > beantwortet die Norm eindeutig. Zitat aus dem C99 draft N1256:
> > |
> > | 6.5.3.4 The sizeof operator
> > |
> > | 3 [...]
> > | When applied to an operand that has array type, the result is the
> > | total number of bytes in the array. When applied to an operand that
> > | has structure or union type, the result is the total number of bytes
> > | in such an object, including internal and trailing padding.
> > ^^^^^^^^^ ^^^^^^^^^^^^^^^^
> >
> > Die Frage, ob dieses Padding vorhanden sein *muss* (passend für das
> > nötige Alignment der Zielmaschine), blieb aber offen.
>
> Das kommt jetzt darauf an, was Du mit "muss" und "passend" meinst.
>
> Prinzipiell könnte der Compiler immer Code erzeugen, der auf jedes Byte
> einzeln zugreift, und hätte dann keine Alignment-Requirements. Das wäre
> aber sehr ineffizient und für manche (hardware-nahen) Anwendungen könnte
> man ihn gar nicht verwenden. Oder er könnte z.B. bei der x86-Architektur
> (bei der unaligned Zugriffe von der Hardware erledigt werden und daher
> nur ein bisschen langsamer sind) auf Alignment verzichten.

Mit GCC und gepackten Strukturen:
------------------------------------------------------------------------
#include <stdlib.h>
#include <stdio.h>

struct foo
{ int w;
char x;
int y;
char z;
} __attribute__((packed));

int main(void)
{ struct foo bar[2] = { { 1, 'a', 2, 'b' }, { 3, 'c', 4, 'd' } };

printf("sizeof (struct foo) : %u\n", (unsigned int)sizeof (struct foo));
printf("sizeof bar : %u\n", (unsigned int)sizeof bar);
printf("bar[1].y : %d\n", bar[1].y);

return 0;
} ------------------------------------------------------------------------

Ergibt auf NetBSD/amd64:
|
| sizeof (struct foo) : 10
| sizeof bar : 20
| bar[1].y : 4

Der Assembler-Code sieht gleich aus, wie zu erwarten war.
GCC für SPARC müsste da verschiedenen Code erzeugen.

Subject: Re: Padding von Strukturen
From: Michael Bäuerle
Newsgroups: de.comp.lang.c
Date: Mon, 29 Jan 2024 13:23 UTC
References: 1 2 3
Path: i2pn2.org!rocksolid2!news.neodome.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: michael....@stz-e.de (Michael Bäuerle)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Mon, 29 Jan 2024 14:23:09 +0100 (CET)
Lines: 39
Message-ID: <AABlt6a9Qg8AAAI9.A3.flnews@WStation5.stz-e.de>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de> <up2p80.50o.1@stefan.msgid.phost.de> <slrnur9ppk.23re3.hjp-usenet4@trintignant.hjp.at>
Reply-To: Michael Bäuerle <michael.baeuerle@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net LSp+/IdMjkQ4FOMs+y2T9w+JrFvRdmTVukZbeVLO2olEk66RlR
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:Ai24VFprhe9W4wPVMe1EgVABnRI= sha256:maBeJIHwsP7Q7OYu9Rane/I0exPkRRmkOurqNEdZ0ew= sha1:RQh+oAMcqD3hUxMqNGlnRviiY+s= sha256:1yDeQq0PkRdWx9S+j6/hCsNAyvR90oMInMPteMkbUBI=
Injection-Date: Mon, 29 Jan 2024 13:23:09 -0000
User-Agent: flnews/1.2.1pre6 (for NetBSD)
View all headers

Peter J. Holzer wrote:
> On 2024-01-27 10:25, Stefan Reuther <stefan.news@arcor.de> wrote:
> >
> > [...]
> > Allerdings gibt es dieses Beispiel in n1548 (C11) 6.5.3.4:
> >
> > # EXAMPLE 2
> > # Another use of the sizeof operator is to compute the number of
> > # elements in an array:
> > # sizeof array / sizeof array[0]
> >
> > Ein Beispiel ist zwar nicht normativ, deutet aber schon an, dass das so
> > gemeint ist.
>
> Ja, das habe ich auch gefunden. Zusätzlich:
>
> Kapitel 6.2.5, Absatz 20 beschreibt Arrays als "contiguously allocated".
> Leider fallen mir zwei mögliche Interpretationen davon ein, von denen
> nur eine Padding zwischen den Members ausschließt. Ist also auch nicht
> ganz eindeutig.
>
> Der Standard erlaubt Padding explizit für Integer-Typen, Structs und
> Unions und definiert das Verhalten. Padding innerhalb eines Arrays wird
> soweit ich sehe nirgends erwähnt. Das kann man jetzt auch wieder auf
> zwei Arten auslegen ("Ist offensichtlich nicht vorgesehen, sonst stünde
> es da" oder "Ist nicht verboten, daher ist es erlaubt").
>
> Die Rationale zu C89 schreibt auf S. 51:
>
> | * if necessary, a hole is placed on the end to make the structure big
> | enough to pack tightly into arrays and maintain proper alignment.
>
> Das ist natürlich auch nicht normativ.
>
> Insgesamt würde ich sagen, dass die Intention des Standards klar ist,
> auch wenn der normative Text nicht eindeutig ist.

Sehe ich auch so. Ich war nur nicht sicher, ob ich vielleicht etwas
übersehen habe.

Subject: Re: Padding von Strukturen
From: Stefan Reuther
Newsgroups: de.comp.lang.c
Date: Mon, 29 Jan 2024 17:02 UTC
References: 1 2 3
Path: i2pn2.org!rocksolid2!news.neodome.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: stefan.n...@arcor.de (Stefan Reuther)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Mon, 29 Jan 2024 18:02:12 +0100
Lines: 42
Message-ID: <up8p75.5k8.1@stefan.msgid.phost.de>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
<slrnur7ut6.1vogh.hjp-usenet4@trintignant.hjp.at>
<AABlt6WrK-wAAAI9.A3.flnews@WStation5.stz-e.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 6iUXFKG4i7gcntxAVxjYLAi+9S05pFoSMjV5rMPn2dQ5dr6E49
Cancel-Lock: sha1:MHgQQ6nCqlSzI7fJeV8PxTpfLMY= sha256:+NPv7vTDEU77C95MB8NcqhGJfTxhJUCT68I8Pai6SyA=
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
Thunderbird/68.12.1 Hamster/2.1.0.1538
In-Reply-To: <AABlt6WrK-wAAAI9.A3.flnews@WStation5.stz-e.de>
View all headers

Am 29.01.2024 um 14:18 schrieb Michael Bäuerle:
> Peter J. Holzer wrote:
>> Prinzipiell könnte der Compiler immer Code erzeugen, der auf jedes Byte
>> einzeln zugreift, und hätte dann keine Alignment-Requirements. Das wäre
>> aber sehr ineffizient und für manche (hardware-nahen) Anwendungen könnte
>> man ihn gar nicht verwenden. Oder er könnte z.B. bei der x86-Architektur
>> (bei der unaligned Zugriffe von der Hardware erledigt werden und daher
>> nur ein bisschen langsamer sind) auf Alignment verzichten.
>
> Mit GCC und gepackten Strukturen:
> ------------------------------------------------------------------------
> #include <stdlib.h>
> #include <stdio.h>
[...]
> Ergibt auf NetBSD/amd64:
> |
> | sizeof (struct foo) : 10
> | sizeof bar : 20
> | bar[1].y : 4
>
> Der Assembler-Code sieht gleich aus, wie zu erwarten war.
> GCC für SPARC müsste da verschiedenen Code erzeugen.

Probier's aus: https://gcc.godbolt.org/z/sP8GGzvza

Ich hab hiermit probiert:

struct x {
int a;
char b;
} __attribute__((packed));

int get(struct x* p)
{
return p->a;
}

Ja, für SPARC (oder RISC-V, ARM-V7, ...) stoppelt der gcc da den int aus
4 Einzel-Byte-Loads zusammen.

Stefan

Subject: Re: Padding von Strukturen
From: Rainer Weikusat
Newsgroups: de.comp.lang.c
Date: Tue, 30 Jan 2024 16:06 UTC
References: 1
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rweiku...@talktalk.net (Rainer Weikusat)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Tue, 30 Jan 2024 16:06:20 +0000
Lines: 44
Message-ID: <87v87ast4z.fsf@doppelsaurus.mobileactivedefense.com>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 4X2AIFV499pLFGcNG0bgjgtTBiTYXAcok3Jmkk+radJAoDkxU=
Cancel-Lock: sha1:hIxyWXm/XiAOVX7zX3mVe3bmMsE= sha1:NQBcjP9EO3jjX6ZxjFEh6IL0kVg= sha256:FcRoRde57QAWZBLLCRgAk4aPt7klw3vjVSgd5aP+fSM=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
View all headers

Michael Bäuerle <michael.baeuerle@stz-e.de> writes:

[...]

> | 6.5.6 Additive operators
> |
> | 8 [...] When an expression that has integer type is added to or
> | subtracted from a pointer, [...]
> | If the pointer operand points to an element of an array object, and
> | the array is large enough, the result points to an element offset from
> | the original element such that the difference of the subscripts of the
> | resulting and original array elements equals the integer expression.
>
> Da steht nicht, dass der Offset ein Vielfaches der Größe der Elemente
> (entsprechend dem was sizeof liefert) sein muss.

Ist er ja auch nicht. Wie kommt man denn um Himmels Willen auf so eine
vollkommen groteske Idee?

-----
#include <stdio.h>

struct salami {
char *nirgendwo;
int irgendwas[2];
};

static struct salami spd[5];

int main(void)
{ struct salami *daresalami;

daresalami = spd + 3;
printf("Offset %zd, Elementgroesse %zd\n", daresalami - spd, sizeof(*spd));
return 0;
} ----

Gibt für mich

Offset 3, Elementgroesse 16

aus. Das drei kein Vielfaches von 16 ist, sollte klar sein.

Subject: Re: Padding von Strukturen
From: Bonita Montero
Newsgroups: de.comp.lang.c
Organization: A noiseless patient Spider
Date: Fri, 2 Feb 2024 07:26 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Fri, 2 Feb 2024 08:26:20 +0100
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <upi5ep$2gojo$1@raubtier-asyl.eternal-september.org>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
<87v87ast4z.fsf@doppelsaurus.mobileactivedefense.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 2 Feb 2024 07:26:17 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="5a8f9de086da4d6c35312f4f648840ef";
logging-data="2646648"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/7hAZo65Z5VBodK3a5L6UDhazvFgYUL3c="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:OvMUptkUT3799axyqx2NtOnnbhs=
In-Reply-To: <87v87ast4z.fsf@doppelsaurus.mobileactivedefense.com>
Content-Language: de-DE
View all headers

Am 30.01.2024 um 17:06 schrieb Rainer Weikusat:
> Michael Bäuerle <michael.baeuerle@stz-e.de> writes:
>
> [...]
>
>> | 6.5.6 Additive operators
>> |
>> | 8 [...] When an expression that has integer type is added to or
>> | subtracted from a pointer, [...]
>> | If the pointer operand points to an element of an array object, and
>> | the array is large enough, the result points to an element offset from
>> | the original element such that the difference of the subscripts of the
>> | resulting and original array elements equals the integer expression.
>>
>> Da steht nicht, dass der Offset ein Vielfaches der Größe der Elemente
>> (entsprechend dem was sizeof liefert) sein muss.
>
> Ist er ja auch nicht. Wie kommt man denn um Himmels Willen auf so eine
> vollkommen groteske Idee?
>
> -----
> #include <stdio.h>
>
> struct salami {
> char *nirgendwo;
> int irgendwas[2];
> };
>
> static struct salami spd[5];
>
> int main(void)
> {
> struct salami *daresalami;
>
> daresalami = spd + 3;
> printf("Offset %zd, Elementgroesse %zd\n", daresalami - spd, sizeof(*spd));
> return 0;
> }
> ----
>
> Gibt für mich
>
> Offset 3, Elementgroesse 16
>
> aus. Das drei kein Vielfaches von 16 ist, sollte klar sein.

Ja, man kann das auch mutwillig missverstehen was Michael
geschrieben hat. Er meinte natürlich die Byte-Offsets, also
wenn Du vorher die Pointer nach char * gecastet hättest.

Subject: Re: Padding von Strukturen
From: Helmut Schellong
Newsgroups: de.comp.lang.c
Date: Sun, 3 Mar 2024 20:16 UTC
References: 1
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: var...@schellong.biz (Helmut Schellong)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Sun, 3 Mar 2024 21:16:15 +0100
Message-ID: <us2lq9$t4vj$1@solani.org>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
Reply-To: rip@schellong.biz
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 3 Mar 2024 20:16:09 -0000 (UTC)
Injection-Info: solani.org;
logging-data="955379"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0 SeaMonkey/2.53.18.1
Cancel-Lock: sha1:rozadDxffq6tMqOjuoMELzYz/sE=
X-User-ID: eJwNysEBwCAMAsCVUhMgHUet7D+Cvfch+XCrCBYMH5GfjOISZhw71ESFxz7Z+YLRHhDXfycvFXcQxA==
In-Reply-To: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
View all headers

Michael Bäuerle wrote:
> Ich hatte kürzlich eine Diskussion zum Padding in Strukturen und
> deren Größe. Es ging dabei nicht um das Alignment der Elemente in der
> Struktur, sondern um das Padding am Ende, ob /sizeof/ dieses mitrechnet
> oder nicht und ob es (für das Aligment in einem Array aus solchen
> Strukturen) vorhanden sein muss oder nicht.
>
> Im Kern ging es um die Frage, ob es in C90 bzw. C99 *portabel* möglich
> ist die Größe einer Struktur mit der Anzahl der Elementen eines Arrays
> zu multiplizieren, um den Speicher für ein solches Array z.B. mit:
>
> size_t n = 3;
> struct foo *p = malloc(n * sizeof (struct foo));
>
> anzufordern.

Selbstverständlich!

> Die Frage, ob sizeof das Padding am Ende einer Struktur mitrechnet,
> beantwortet die Norm eindeutig. Zitat aus dem C99 draft N1256:
> |
> | 6.5.3.4 The sizeof operator
> |
> | 3 [...]
> | When applied to an operand that has array type, the result is the
> | total number of bytes in the array. When applied to an operand that
> | has structure or union type, the result is the total number of bytes
> | in such an object, including internal and trailing padding.
> ^^^^^^^^^ ^^^^^^^^^^^^^^^^

Deshalb schrieb ich vorstehend, was ich dort schrieb.

> Die Frage, ob dieses Padding vorhanden sein *muss* (passend für das
> nötige Alignment der Zielmaschine), blieb aber offen.
> Zitat aus dem C99 draft N1256:
> |
> | 6.7.2.1 Structure and union specifiers
> |
> | [...]
> | 12 Each non-bit-field member of a structure or union object is
> | aligned in an implementation-defined manner appropriate to its
> | type.
> | [...]
> | 15 There may be unnamed padding at the end of a structure or union.
>
> Das würde dem Compiler auch erlauben das Padding am Ende der Struktur
> wegzulassen, so dass sizeof es nicht mitrechnet, solange er z.B.:
>
> struct foo bar[3];
>
> mit separatem Padding korrekt anordnen kann und Zugriffe mit bar[n]
> diese Anordnung berücksichtigen. Auch für Zeiger + Integer könnte das
> so funktionieren. Zitat aus dem C99 draft N1256:

Der Compiler darf Padding am Ende nicht weglassen, sofern es zum Alignment
des Struktur-Starts benötigt wird - wegen "may be".

> |
> | 6.5.6 Additive operators
> |
> | 8 [...] When an expression that has integer type is added to or
> | subtracted from a pointer, [...]
> | If the pointer operand points to an element of an array object, and
> | the array is large enough, the result points to an element offset from
> | the original element such that the difference of the subscripts of the
> | resulting and original array elements equals the integer expression.
>
> Da steht nicht, dass der Offset ein Vielfaches der Größe der Elemente
> (entsprechend dem was sizeof liefert) sein muss.

Das muß dort auch nicht stehen.
Oben ist erklärt, daß z.B. der Ausdruck 'a+7' um sieben _Elemente_ weiterspringt.
Das ist eine normative Festlegung!
Und die Zahl 7 dürfte jeder Wert von long long sein.
Die Größe der Elemente in Byte wird folglich automatisch berücksichtigt.
In Byte: adresse7 = a + 7 * sizeof(*a);
In meinen C-Büchern habe ich Vorstehendes ausdrücklich erklärt.

Arrays in C enthalten kein Padding, allerdings seine Elemente können Padding enthalten.
Das ist ein eminenter Unterschied!

Seit etwa 20 Jahren sehe ich, daß der Standard nicht selten nicht ganz richtig interpretiert wird.
Auch oben wird etwas gesehen, was gar nicht da ist.

Es hatte mal jemand geargwöhnt, daß ein Array Lücken enthalten darf, weil ein Ausschluß dessen
im Standard nicht aufzufinden ist.
Für diesen Argwohn besteht jedoch kein Grund!
Oben werden doch Strukturen und Unionen hinsichtlich ihres möglichen Paddings definiert.
Wenn Arrays Padding enthalten dürften, müßte in der Definition eines Arrays
ein solches Padding entsprechend definiert sein - ist es aber nicht.

|109) Two objects may be adjacent in memory because they are adjacent elements of a larger array
|or adjacent members of a structure with no padding between them, or because the implementation
|chose to place them so, even though they are unrelated.

--
Mit freundlichen Grüßen
Helmut Schellong

Subject: Re: Padding von Strukturen
From: Bonita Montero
Newsgroups: de.comp.lang.c
Organization: A noiseless patient Spider
Date: Mon, 22 Apr 2024 07:53 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Mon, 22 Apr 2024 09:53:48 +0200
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <v0552a$r8b6$1@raubtier-asyl.eternal-september.org>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
<us2lq9$t4vj$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 22 Apr 2024 09:53:47 +0200 (CEST)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="41b6485d5193052e41e8eaeab9084478";
logging-data="893286"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX182SHOsQ77uVL+EE1y8MOqeJNQTcdYNeXk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:CZ4MXVR2JJ5GL0oFSdOgSW9OaKY=
In-Reply-To: <us2lq9$t4vj$1@solani.org>
Content-Language: de-DE
View all headers

Am 03.03.2024 um 21:16 schrieb Helmut Schellong:

> Das ist eine normative Festlegung!
> Und die Zahl 7 dürfte jeder Wert von long long sein.

Auf 32-Bit-Plattformen hast Du da unrecht. Wenns ne Variable ist
nimmt man an der Stelle einfach ptrdiff_t wenn man das Vorzeichen
braucht, ansonsten size_t.
In C++ ist das ähnlich bzw. wenn ich mit einem Iterator auf einem
Vektor rechne ist der +-Operator mit ptrdiff_t überladen und der
indizierte Array-Operator [] mit size_t. Das gibt 1:1 die natürli-
chen Eigenschaften der Register wieder wie die auch für C gelten.

> Seit etwa 20 Jahren sehe ich, daß der Standard nicht selten nicht
> ganz richtig interpretiert wird.

Das ist ein sprachliches Problem bzw. die Leute gehen dennoch
korrekt mit der Sprache um.

Subject: Re: Padding von Strukturen
From: Helmut Schellong
Newsgroups: de.comp.lang.c
Date: Tue, 23 Apr 2024 17:11 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: var...@schellong.biz (Helmut Schellong)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Tue, 23 Apr 2024 19:11:33 +0200
Message-ID: <v08q41$b7p7$1@solani.org>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
<us2lq9$t4vj$1@solani.org>
<v0552a$r8b6$1@raubtier-asyl.eternal-september.org>
Reply-To: rip@schellong.biz
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 23 Apr 2024 17:11:29 -0000 (UTC)
Injection-Info: solani.org;
logging-data="368423"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:fOTvaB9ISvX9SNJzydt53qYZueA=
X-User-ID: eJwFwQkBwDAIA0BLfAkgp+3Av4Tdwal8GQQDi7XPZMxse5RlVe2j5+ZGSTfLV7xvy8hBPuIHBLMQJQ==
In-Reply-To: <v0552a$r8b6$1@raubtier-asyl.eternal-september.org>
View all headers

Bonita Montero wrote:
> Am 03.03.2024 um 21:16 schrieb Helmut Schellong:
>
>> Das ist eine normative Festlegung!
>> Und die Zahl 7 dürfte jeder Wert von long long sein.
>
> Auf 32-Bit-Plattformen hast Du da unrecht. Wenns ne Variable ist
> nimmt man an der Stelle einfach ptrdiff_t wenn man das Vorzeichen
> braucht, ansonsten size_t.

Es kommt auf die Dokumentation des Compilers und den Inhalt derjenigen
C-Standards an, mit denen der betreffende Compiler konform geht.
Ich habe schon auf 16bit-uC mit dem 64bit breiten Typ double gearbeitet.

> In C++ ist das ähnlich bzw. wenn ich mit einem Iterator auf einem
> Vektor rechne ist der +-Operator mit ptrdiff_t überladen und der
> indizierte Array-Operator [] mit size_t. Das gibt 1:1 die natürli-
> chen Eigenschaften der Register wieder wie die auch für C gelten.
>
>> Seit etwa 20 Jahren sehe ich, daß der Standard nicht selten nicht
>> ganz richtig interpretiert wird.
>
> Das ist ein sprachliches Problem bzw. die Leute gehen dennoch
> korrekt mit der Sprache um.

Warum argumentierst Du oben mit einer 32-Bit-Plattform?
Auch auf einer 8-Bit-Plattform kann mit 64bit-double und -long long gerechnet werden.
Gemäß dem Inhalt des betreffenden C-Standards.
Es gibt dann halt compiler-interne Library-Funktionen, die das machen.

--
Mit freundlichen Grüßen
Helmut Schellong

Subject: Re: Padding von Strukturen
From: Bonita Montero
Newsgroups: de.comp.lang.c
Organization: A noiseless patient Spider
Date: Tue, 23 Apr 2024 17:25 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Tue, 23 Apr 2024 19:25:50 +0200
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <v08quv$1oa3d$1@raubtier-asyl.eternal-september.org>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
<us2lq9$t4vj$1@solani.org>
<v0552a$r8b6$1@raubtier-asyl.eternal-september.org>
<v08q41$b7p7$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 23 Apr 2024 19:25:51 +0200 (CEST)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="70734427025ac6155b044ec072dc2533";
logging-data="1845357"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19OPgokyhkJSoPDVr5rHhlSveai8ry3xPs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:LShO2MpEuuKbJQrlDYa7zGr/EvM=
Content-Language: de-DE
In-Reply-To: <v08q41$b7p7$1@solani.org>
View all headers

Am 23.04.2024 um 19:11 schrieb Helmut Schellong:
> Bonita Montero wrote:
>> Am 03.03.2024 um 21:16 schrieb Helmut Schellong:
>>
>>> Das ist eine normative Festlegung!
>>> Und die Zahl 7 dürfte jeder Wert von long long sein.
>>
>> Auf 32-Bit-Plattformen hast Du da unrecht. Wenns ne Variable ist
>> nimmt man an der Stelle einfach ptrdiff_t wenn man das Vorzeichen
>> braucht, ansonsten size_t.
>
> Es kommt auf die Dokumentation des Compilers und den Inhalt derjenigen
> C-Standards an, mit denen der betreffende Compiler konform geht.

Hä ? Offsets und Indizes nimmt man immer als ptrdiff_t oder size_t;d
das funktioniert mit jeder heutigen Plattform.

> Ich habe schon auf 16bit-uC mit dem 64bit breiten Typ double gearbeitet.

Was hat das damit zu tun ?

>> In C++ ist das ähnlich bzw. wenn ich mit einem Iterator auf einem
>> Vektor rechne ist der +-Operator mit ptrdiff_t überladen und der
>> indizierte Array-Operator [] mit size_t. Das gibt 1:1 die natürli-
>> chen Eigenschaften der Register wieder wie die auch für C gelten.
>>
>>> Seit etwa 20 Jahren sehe ich, daß der Standard nicht selten nicht
>>> ganz richtig interpretiert wird.
>>
>> Das ist ein sprachliches Problem bzw. die Leute gehen dennoch
>> korrekt mit der Sprache um.
>
> Warum argumentierst Du oben mit einer 32-Bit-Plattform?

Was hat das mit der Stelle zu tun wo Du diesen Einwand machst ?
Ich hab einfach gesagt, dass ein *ull ungünstig für eine 32-Bit
Plattform ist weil die eben nicht mit 64-bittigen Offsets und
Indizes umgehen kann.

> Auch auf einer 8-Bit-Plattform kann mit 64bit-double und -long long
> gerechnet werden.

Mein Gott, Du bist ja echt wirr.

> Gemäß dem Inhalt des betreffenden C-Standards.
> Es gibt dann halt compiler-interne Library-Funktionen, die das machen.
>
>

Subject: Re: Padding von Strukturen
From: Helmut Schellong
Newsgroups: de.comp.lang.c
Date: Tue, 23 Apr 2024 18:41 UTC
References: 1 2 3 4 5
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: var...@schellong.biz (Helmut Schellong)
Newsgroups: de.comp.lang.c
Subject: Re: Padding von Strukturen
Date: Tue, 23 Apr 2024 20:41:13 +0200
Message-ID: <v08vc3$bb06$1@solani.org>
References: <AABls+L881gAAAIP.A3.flnews@WStation5.stz-e.de>
<us2lq9$t4vj$1@solani.org>
<v0552a$r8b6$1@raubtier-asyl.eternal-september.org>
<v08q41$b7p7$1@solani.org>
<v08quv$1oa3d$1@raubtier-asyl.eternal-september.org>
Reply-To: rip@schellong.biz
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 23 Apr 2024 18:41:07 -0000 (UTC)
Injection-Info: solani.org;
logging-data="371718"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:/RkqvLIEAgCbXkIvkcFjA9q8Xwo=
X-User-ID: eJwFwYEBwDAEBMCVCP9inCL2H6F3MCo7nKBjsVJ3ZIz1IOUBU7c5udDsOeSe/mo7Ozaf3fkBGQMRaQ==
In-Reply-To: <v08quv$1oa3d$1@raubtier-asyl.eternal-september.org>
View all headers

Bonita Montero wrote:
> Am 23.04.2024 um 19:11 schrieb Helmut Schellong:
>> Bonita Montero wrote:
>>> Am 03.03.2024 um 21:16 schrieb Helmut Schellong:
>>>
>>>> Das ist eine normative Festlegung!
>>>> Und die Zahl 7 dürfte jeder Wert von long long sein.
>>>
>>> Auf 32-Bit-Plattformen hast Du da unrecht. Wenns ne Variable ist
>>> nimmt man an der Stelle einfach ptrdiff_t wenn man das Vorzeichen
>>> braucht, ansonsten size_t.
>>
>> Es kommt auf die Dokumentation des Compilers und den Inhalt derjenigen
>> C-Standards an, mit denen der betreffende Compiler konform geht.
>
> Hä ? Offsets und Indizes nimmt man immer als ptrdiff_t oder size_t;d
> das funktioniert mit jeder heutigen Plattform.
>
>> Ich habe schon auf 16bit-uC mit dem 64bit breiten Typ double gearbeitet.
>
> Was hat das damit zu tun ?
>
>>> In C++ ist das ähnlich bzw. wenn ich mit einem Iterator auf einem
>>> Vektor rechne ist der +-Operator mit ptrdiff_t überladen und der
>>> indizierte Array-Operator [] mit size_t. Das gibt 1:1 die natürli-
>>> chen Eigenschaften der Register wieder wie die auch für C gelten.
>>>
>>>> Seit etwa 20 Jahren sehe ich, daß der Standard nicht selten nicht
>>>> ganz richtig interpretiert wird.
>>>
>>> Das ist ein sprachliches Problem bzw. die Leute gehen dennoch
>>> korrekt mit der Sprache um.
>>
>> Warum argumentierst Du oben mit einer 32-Bit-Plattform?
>
> Was hat das mit der Stelle zu tun wo Du diesen Einwand machst ?
> Ich hab einfach gesagt, dass ein *ull ungünstig für eine 32-Bit
> Plattform ist weil die eben nicht mit 64-bittigen Offsets und
> Indizes umgehen kann.
>
>> Auch auf einer 8-Bit-Plattform kann mit 64bit-double und -long long gerechnet werden.
>
> Mein Gott, Du bist ja echt wirr.
>
>> Gemäß dem Inhalt des betreffenden C-Standards.
>> Es gibt dann halt compiler-interne Library-Funktionen, die das machen.

Beenden wir doch diesen Scheiß hier.

--
Mit freundlichen Grüßen
Helmut Schellong


rocksolid / de.comp.lang.c / Re: Padding von Strukturen

1
server_pubkey.txt

rocksolid light 0.9.136
clearnet tor