strukturen fuellen
Markus Wenke
Noch eine frage zum Linux-Compiler gcc:
wenn ich z.B diese Struktur habe:
typedef struct {
long p;
char *name;
long size;
} TestStruct
und diese Struktur so fülle:
TestStruct S1 [4] =
{
{ 1 "", 0 },
{ 2 "name2", 3 },
{ 3 "", 5 },
{ 4, "xyz", 0 }
};
dann funtioniert alles, wenn ich aber die "{}" un den einzelnen
Einträgen weglasse, kommt der gcc damit nicht klar, der compiliert
ordentlich, packt die Einträge nicht an der richtigen Stelle.
Der M$-Compiler packt das richtig.
Gibrt es eine Möglichkeit unter Linux die Struktur ohne die "{}" um die
einzelnen Einträge richtig zu füllen?
Das problem ist, das ich ein rel. großes Projekt von M$->Linux portiere,
und die ganzen M$'ler nicht gerne diese "{}" sehen.
Wenn es unter Linux irgendwie geht, muss ich auch nicht die ganzen "{}"
setzen :-).
Ich benutze beim kompilieren die Option "-fpack-struct".
Danke im voraus
Markus Wenke
Jens Schweikhardt
in <3D328BB...@whoisup.de>:
...
# wenn ich z.B diese Struktur habe:
#
# typedef struct {
# long p;
# char *name;
# long size;
# } TestStruct
#
# und diese Struktur so fülle:
#
# TestStruct S1 [4] =
# {
# { 1 "", 0 },
# { 2 "name2", 3 },
# { 3 "", 5 },
# { 4, "xyz", 0 }
# };
#
# dann funtioniert alles, wenn ich aber die "{}" un den einzelnen
# Einträgen weglasse, kommt der gcc damit nicht klar, der compiliert
# ordentlich, packt die Einträge nicht an der richtigen Stelle.
Ohne die {} ist es kein korrektes C. Lies mal ISO C99 6.7.8 Initialization.
Kostet nur US$18.
# Der M$-Compiler packt das richtig.
Nein; er macht zufällig mit inkorrektem C das, was Du erwartest.
# Gibrt es eine Möglichkeit unter Linux die Struktur ohne die "{}" um die
# einzelnen Einträge richtig zu füllen?
Warum willst Du inkorrektes C schreiben?
# Das problem ist, das ich ein rel. großes Projekt von M$->Linux portiere,
# und die ganzen M$'ler nicht gerne diese "{}" sehen.
Was heißt "M$'ler"? Compiler? Programmierer? Welche Fehlermeldung?
# Wenn es unter Linux irgendwie geht, muss ich auch nicht die ganzen "{}"
# setzen :-).
Das solltest Du aber.
# Ich benutze beim kompilieren die Option "-fpack-struct".
Das hat keine Relevanz.
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Markus Wenke
> Kostet nur US$18.
>
> # Der M$-Compiler packt das richtig.
>
> Nein; er macht zufällig mit inkorrektem C das, was Du erwartest.
Ist mir schon klar
>
> # Gibrt es eine Möglichkeit unter Linux die Struktur ohne die "{}" um die
> # einzelnen Einträge richtig zu füllen?
>
> Warum willst Du inkorrektes C schreiben?
>
> # Das problem ist, das ich ein rel. großes Projekt von M$->Linux portiere,
> # und die ganzen M$'ler nicht gerne diese "{}" sehen.
>
> Was heißt "M$'ler"? Compiler? Programmierer? Welche Fehlermeldung?
Mit M$'ler meine ich die Programmierer hier,... (Die kennen alle nur MS)
>
> # Wenn es unter Linux irgendwie geht, muss ich auch nicht die ganzen "{}"
> # setzen :-).
>
> Das solltest Du aber.
>
Ich weiss, ich stehe hier aber nicht in der Position so etwas zu
entscheiden, aber wenn es nicht anders geht,.. ;-)
> # Ich benutze beim kompilieren die Option "-fpack-struct".
>
> Das hat keine Relevanz.
>
Danke
Andreas Krennmair
> > # Wenn es unter Linux irgendwie geht, muss ich auch nicht die ganzen "{}"
> > # setzen :-).
> >
> > Das solltest Du aber.
> >
> Ich weiss, ich stehe hier aber nicht in der Position so etwas zu
> entscheiden, aber wenn es nicht anders geht,.. ;-)
Im Zweifelsfall kann man immer mit dem Standard argumentieren.
mfg, ak
Markus Wenke
Mache ich ja auch,.. :-)
Rolf Magnus
>>> Ich weiss, ich stehe hier aber nicht in der Position so etwas zu
>>> entscheiden, aber wenn es nicht anders geht,.. ;-)
>>
>>
>> Im Zweifelsfall kann man immer mit dem Standard argumentieren.
>>
>> mfg, ak
>
> Mache ich ja auch,.. :-)
Das ist auf jeden Fall besser als zu sagen "unter Linux geht das nicht". Das
wird nur Ablehnung gegen Linux bringen. Konformität zum Standard sollte man
aber von jedem C-Programmierer erwarten können. Eventuell brauchen die
Programmierer mal einen nicht von M$ veranstalteten Auffrischungskurs in
C-Programmierung.
Markus Wenke
NeNe, die MS-Programmierer haben hier eine Menge auf dem Kasten!! Die
kennen halt nur nichts anderes,...
(Ich kenne nur Linux, und ich denke es gibt bei Linux auch einige Sachen
die nicht standard sind, und bei MS schon. (wahrscheinlich nicht viele :-)))
Heinrich Schramm
>(Ich kenne nur Linux, und ich denke es gibt bei Linux auch einige Sachen
>die nicht standard sind, und bei MS schon. (wahrscheinlich nicht viele :-)))
Wobei gcc gar nicht so viel mit Linux zu tun hat. Es ist ein Compiler,
der auf vielen Plattformen laeuft (vgl.
<http://gcc.gnu.org/gcc-3.1/buildstat.html>), u.a. auch auf Windows (mit
Cygwin).
Gruss Heiner
Juergen Ilse
Markus Wenke <M.W...@whoisup.de> wrote:
[...]
>> Eventuell brauchen die
>> Programmierer mal einen nicht von M$ veranstalteten Auffrischungskurs in
>> C-Programmierung.
> NeNe, die MS-Programmierer haben hier eine Menge auf dem Kasten!! Die
> kennen halt nur nichts anderes,...
Dann braeuchten sie den oben erwaehnten Kurs vielleicht trotzdem, denn
sie koennen demnach anscheinend kein C programmieren, sondern hoechstens
"M$ Visual C++" ...
> (Ich kenne nur Linux, und ich denke es gibt bei Linux auch einige Sachen
> die nicht standard sind, und bei MS schon. (wahrscheinlich nicht viele :-)))
Es geht nicht um evt. systemspezifische Libraries oder dergleichen,
es geht um Dinge, die laut C-standard eindeutig *Fehler* sind (und
wenn irgendein Compiler so etwas tatsaechlich ohne Meldungen in Code
umsetzt, ist der Compiler *eigentlich* kaputt). Der Mehraufwand um
C- oder C++-Programme statt "M$ Visual C++ Programme" zu schreiben
duerfte nicht allzu gross sein, man muss den Leuten nur erklaeren,
warum das sinnvoll ist (und das ist einfach, wenn man ihnen erklaert,
dass ihnen noch nicht einmal jemand garantiert, dass ihr jetziger
Code auf irgendeinem anderen Compiler unter Windows laeuft, schlimmer
noch: es garantiert ihnen noch nicht einmal jemand, dass der Code
sich mit der naechsten Version des M$-Compilers immer noch ueber-
setzen laesst ...).
Tschuess,
Juergen Ilse (il...@usenet-verwaltung.org)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Stefan Reuther
Jens Schweikhardt <use...@schweikhardt.net> wrote:
> Markus Wenke <M.W...@whoisup.de> wrote
> # wenn ich z.B diese Struktur habe:
> #
> # typedef struct {
> # long p;
> # char *name;
> # long size;
> # } TestStruct
> #
> # und diese Struktur so fülle:
> #
> # TestStruct S1 [4] =
> # {
> # { 1 "", 0 },
> # { 2 "name2", 3 },
> Ohne die {} ist es kein korrektes C. Lies mal ISO C99 6.7.8 Initialization.
> Kostet nur US$18.
Huch?
Wie ist dann das hier zu verstehen? (6.7.8 im *Draft*);
| [#20] If the aggregate contains elements or members that are
| aggregates or unions, or if the first member of a union is
| an aggregate or union, these rules apply recursively to the
| subaggregates or contained unions. If the initializer of a <--
| subaggregate or contained union begins with a left brace, <--
| the initializers enclosed by that brace and its matching
| right brace initialize the elements or members of the
| subaggregate or the first member of the contained union.
| Otherwise, only enough initializers from the list are taken <--
| to account for the elements or members of the subaggregate
| or the first member of the contained union; any remaining
| initializers are left to initialize the next element or
| member of the aggregate of which the current subaggregate or
| contained union is a part.
Der gcc compiliert das auch wunderprimstens.
typedef struct { long p; char* name; long size; } TestStruct;
TestStruct S1[4] = {
1, "", 0,
2, "name2", 3,
3, "", 5,
4, "xyz", 0
};
Mit -Wall bekommt man eine Warnung ("missing braces around
initializer"), sonst nix. -fpack-struct macht keinen
Unterschied.
Stefan
Rolf Magnus
...oder mingw
Rolf Magnus
> NeNe, die MS-Programmierer haben hier eine Menge auf dem Kasten!! Die
> kennen halt nur nichts anderes,...
Naja, mag ja sein, daß sie "eine Menge auf dem Kasten" haben. Aber daß sie
nichts anderes als fehlerhafte C-Konstrukte kennen ist doch bedenklich. Ich
will gar nicht sagen, sie seien schlechte Programmierer, sondern nur, daß
sie eben den C-Standard nicht so genau kennen.
> (Ich kenne nur Linux, und ich denke es gibt bei Linux auch einige Sachen
> die nicht standard sind, und bei MS schon. (wahrscheinlich nicht viele
> :-)))
gcc kennt auch ein paar Erweiterungen. Aber es geht mir gar nicht um Linux
vs. Windows (oder, wie Heinrich schon sagte, korrekter: gcc vs. M$VC++) und
deren Anzahl an nicht-standardkonformen Erweiterungen, sondern darum, daß
man als Programmierer eben wissen sollte, was eine Erweiterung und was Teil
des Standards ist. Und sofern kein triftiger Grund vorliegt, eine
Erweiterung zu nutzen, wähle ich lieber den standardkonformen Weg, um meine
Portabilität nicht unnötig einzuschränken.
Jens Schweikhardt
in <1026737196.irz766%sr...@inf.tu-dresden.de>:
#
# Hallo,
#
# Jens Schweikhardt <use...@schweikhardt.net> wrote:
#> Markus Wenke <M.W...@whoisup.de> wrote
#> # wenn ich z.B diese Struktur habe:
#> #
#> # typedef struct {
#> # char *name;
#> # long size;
#> # } TestStruct
#> #
#> #
#> # TestStruct S1 [4] =
#> # {
#> # { 1 "", 0 },
#
#> Ohne die {} ist es kein korrektes C. Lies mal ISO C99 6.7.8 Initialization.
#> Kostet nur US$18.
#
# Huch?
Tja, ich glaube ich kann mir nur damit herausreden, daß das auch
*mit* {} kein korrektes C ist -- wegen der fehlenden Kommata :-)
# Wie ist dann das hier zu verstehen? (6.7.8 im *Draft*);
# | [#20] If the aggregate contains elements or members that are
# | aggregates or unions, or if the first member of a union is
# | an aggregate or union, these rules apply recursively to the
# | subaggregates or contained unions. If the initializer of a <--
# | subaggregate or contained union begins with a left brace, <--
# | the initializers enclosed by that brace and its matching
# | right brace initialize the elements or members of the
# | subaggregate or the first member of the contained union.
# | Otherwise, only enough initializers from the list are taken <--
# | to account for the elements or members of the subaggregate
# | or the first member of the contained union; any remaining
# | initializers are left to initialize the next element or
# | member of the aggregate of which the current subaggregate or
# | contained union is a part.
#
# Der gcc compiliert das auch wunderprimstens.
# typedef struct { long p; char* name; long size; } TestStruct;
#
# TestStruct S1[4] = {
# 1, "", 0,
# 2, "name2", 3,
# 3, "", 5,
# 4, "xyz", 0
# };
Da habe ich mich wohl wegen anderer Compiler (diab data dcc), die das
auch bemängeln, einlullen lassen. In der Tat ist das korrektes C. Der
Draft hat hier den gleichen Text wie der Standard. Vielen Dank für die
Korrektur.
# Mit -Wall bekommt man eine Warnung ("missing braces around
# initializer"), sonst nix. -fpack-struct macht keinen
# Unterschied.
Meine Vermutung ist, daß viele Compiler hier deswegen warnen, weil es
leicht passieren kann, daß bei Auslassen eines Initialisierers sich die
nachfolgenden Elemente verschieben (was im konkreten Fall nicht so
problematisch sein wird, wegen der unterschiedlichen Typen).
Ich widerrufe hiermit alle Behauptungen, die {} seien erforderlich
(höchtens stilistisch erwünscht), und widme mich wie in solchen Fällen
üblich einem einwöchigen Brain reboot.
Regards,
Jens -- syncing 8 3 3 2 1 1
Markus Wenke
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote
> in <1026737196.irz766%sr...@inf.tu-dresden.de>:
> #
> # TestStruct S1[4] = {
> # 1, "", 0,
> # 2, "name2", 3,
> # 3, "", 5,
> # 4, "xyz", 0
> # };
Dies funktioniert schon, (der gcc nimmt das an) aber die Struktur wird
nicht richtig gefüllt, das merkt man erst an einem seg-fault!!
Ingo van Lil
> TestStruct S1 [4] =
> {
> { 1 "", 0 },
> { 2 "name2", 3 },
> { 3 "", 5 },
> { 4, "xyz", 0 }
> };
>
> dann funtioniert alles, wenn ich aber die "{}" un den einzelnen
> Einträgen weglasse, kommt der gcc damit nicht klar, der compiliert
> ordentlich, packt die Einträge nicht an der richtigen Stelle.
Kannst Du dafuer mal ein kleines Beispielprogramm angeben, dass das
reproduziert? Bei mir (gcc 2.95.3) funktioniert das naemlich problemlos
(abgesehen von einer Warnung).
Tschau,
Ingo
Markus Wenke
> Markus Wenke schrieb:
>
>
>>TestStruct S1 [4] =
>> {
>> { 1 "", 0 },
>> { 2 "name2", 3 },
>> { 3 "", 5 },
>> { 4, "xyz", 0 }
>> };
>>
>>dann funtioniert alles, wenn ich aber die "{}" un den einzelnen
>>Einträgen weglasse, kommt der gcc damit nicht klar, der compiliert
>>ordentlich, packt die Einträge nicht an der richtigen Stelle.
>
>
> Kannst Du dafuer mal ein kleines Beispielprogramm angeben, dass das
> reproduziert? Bei mir (gcc 2.95.3) funktioniert das naemlich problemlos
> (abgesehen von einer Warnung).
>
Morgen, :-)
das compilieren funzt auch, aber die Struktur/Speicherbereich wird nicht
richtig gefüllt.
Ich weiss nicht, ob ich das reproduzieren kann, der fehler taucht in
einem riesigen Projekt auf, mir sehr großen strukturen, ich versuch's
morgen mal,...
Ingo van Lil
> das compilieren funzt auch, aber die Struktur/Speicherbereich wird nicht
> richtig gefüllt.
Hab ich schon verstanden. Ich hab aber in einer Schleife alle Elemente
Deiner Beispielstruktur anzeigen lassen und sie sind alle wie erwartet
initialisiert worden.
Rolf Magnus
> ....
>> # TestStruct S1[4] = {
>> # 1, "", 0,
>> # 2, "name2", 3,
>> # 3, "", 5,
>> # 4, "xyz", 0
>> # };
>> ....
>
> Dies funktioniert schon, (der gcc nimmt das an) aber die Struktur wird
> nicht richtig gefüllt, das merkt man erst an einem seg-fault!!
Also dein Beispiel funktioniert hier, und wenn ich die Werte wieder auslese,
steht da auch das richtige drin. Das gilt für gc 2.95.3 und gcc 3.1.
Stefan Reuther
Woran glaubst du zu erkennen, daß das an der Initialisierung
der Struktur liegt?
<glaskugel> Greifst du vielleicht schreibend auf die
Zeichenketten-Literale zu? Also sowas wie
`S1[1].name[0] = 'X''? </glaskugel>
Freilich, es *könnte* ein Compilerbug sein, allerdings
halte ich das beim gcc für recht unwahrscheinlich. Ich hatte
aber schon einige Fälle, wo der Borland C++-Compiler (Windows)
für Dinge wie
RECT r = { x, y, x+w, y+h };
(als lokale Variable) Code erzeugt hat, der segfaultet,
während er das äquivalente
RECT r;
r.left = x; r.top = y; r.right = x+w; r.bottom = y+h;
korrekt übersetzt hat. Mit dem gcc ist mir das noch nicht
passiert.
Schau mal in den Assemblercode. Und vor allem, schau dir
an, wo *genau* der Segfault auftritt (gcc -g, gdb).
Stefan