Pointer auf Array 2 of int

SeppJ

dachschaden schrieb:

Eine weitere Möglichkeit ist ein Cast.
Wie MatzeHHC schon geschrieben hat, gibt es keinen eigentlichen Unterschied zwischen array und &array . Die Adresse des Arrays ist gleichzeitig die Adresse des ersten Elementes des Arrays. Ein Cast sagt dem Compiler nur, dass er die Fresse halten soll.

Ich bekomm's gerade nicht hin, aber irgendwie ist es bestimmt möglich ein Beispiel zu basteln, wo man damit auf die Fresse fliegt^*. Es sind inkompatible Pointertypen. Einen davon in den anderen zu casten und danach lesend darauf zu zu greifen ist undefiniertes Verhalten. Basta.

^*: Vielleicht irgendwas mit Unions und zusammengesetzte Typen mit ungerader sizeof, bei gleichzeitig strikten Anforderungen ans Alignment. virtual in all seinen Ausprägungen wäre sicher auch ein guter Kandidat, wenn man C++ in Betracht zieht. Irgendwie gibt es bestimmt eine Kombination, das falsch zu biegen.

Dann solltest du dir in keinem Fall die ganzen sockaddr -Typen anschauen. Da macht man ständig Casts von sockaddr_in* bzw. sockaddr_in6* oder auch mal sockaddr_un* . Sind alle untereinander zuweisbar. connect übernimmt zum Beispiel immer nur sockaddr* . Machbar isses auf jeden Fall. Wenn du einen Fehler findest - die glibc-Leute werden sich freuen. Oder vielleicht auch die gcc-Leute, wenn du eine Stelle findest, wo sie das Alignment falsch machen.

SeppJ

Dass das in diesen Fällen funktioniert und auch immer funktionieren wird, bestreit ich gar nicht. Ich bin bloß ebenso sicher, dass man irgendwie einen Fall konstruieren kann, wo die Aussage, dass es egal wäre, ob man arr oder &arr schreibt, zu Problemen führt.

(Und dass das Casten von inkompatiblen Pointertypen Probleme verursachen kann, ist trivial zu zeigen.)

Mein Post bezog sich auf deine dann doch verallgemeinerte Aussage:

SeppJ schrieb:

Es sind inkompatible Pointertypen. Einen davon in den anderen zu casten und danach lesend darauf zu zu greifen ist undefiniertes Verhalten.

volkard

@dachschaden: Es ist nicht naheliegend, daß jemals ein Compiler den UB-Code nicht korrekt übersetzt. Eigentlich.
Aaber, anscheinend benutzt der GCC gelegentlich die schärfstmögliche Auslegung des Standards, um UB-Stellen zu finden und wegzuoptimieren. Also irgendwann kriegen sie Dich.

SeppJ schrieb:

Ich bin bloß ebenso sicher, dass man irgendwie einen Fall konstruieren kann, wo die Aussage, dass es egal wäre, ob man arr oder &arr schreibt, zu Problemen führt.

Der einer Funktion übergebene Wert ist ja gleich. Da sehe ich wenig Spielraum, eine Funktion in Produktivcode zu schmuggeln, um z.B. openssl wieder aufzumachen.

#include <stdio.h>
#include <string.h>

//fills any object with zeros.
//#define INIT_ZERO(x) memset(x,0,sizeof(*(x)))
#define INIT_ZERO(p) testMemset(p,0,sizeof(*(p)))

void testMemset(void* p,int v,size_t n){
	printf("memset(%p,%u,%zu)\n",p,v,n);
}

int main() {
	struct{
		int arr[10];
	} str;
	int arr[10];

	INIT_ZERO(&str);//ok

	INIT_ZERO(&arr);//ok

	//INIT_ZERO(str);//Compilerfehler
//error: invalid type argument of unary '*' (have 'struct <anonymous>')

	//Als alter C-Hase weiß ich ja, daß ich vor Arrays in Aufrufen
	//das & immer weglassen darf. Außer, SeppJ und volki zetteln 
	//eine Verschwörung an…
	INIT_ZERO(arr);//Kein Compilerfehler. 
//Löscht leider nur 4 Bytes statt 40. 

	return 0;
}

@Volkard:
Jau, bin ich bereit, anzuerkennen. Danke dafür.

SeppJ

volkard schrieb:

Der einer Funktion übergebene Wert ist ja gleich. Da sehe ich wenig Spielraum, eine Funktion in Produktivcode zu schmuggeln, um z.B. openssl wieder aufzumachen.

Ich dachte da an irgendwas in der Richtung, wie in C++ bei Mehrfachvererbung und Casts zu Pointern auf die Basisklasse und der Compiler generiert tatsächlich Code für den Cast, der einem die passende Basisklasse gibt. Damit kann man bestimmt irgendwie Schabernack treiben. In reinem C geht da vielleicht auch irgendwie was mit krummen Alignments wo man vielleicht am Ende einen Pointer auf eine falsch ausgerichtete Adresse bekommt. Aber wie gesagt, habe ich noch kein konkretes Beispiel ausgeknobelt.

1. Online-Compiler? Ja klar. m( DAS ist die Zukunft, ganz bestimmt.
Zur Information: jeder ORDENTLICHE Compiler wirft hier eine Warnung.

Wahnsinn Alter, du bist so behämmert das es nur kracht. Checkst du es wirklich nicht ? Lesen... Typischer Fachidiot. Wie er im Buche steht.

machen würde anstatt (*t)[x] - weil du ein Array von Zeigern auf Arrays hättest statt einen Zeiger auf ein Array).

Du kannst Dir gar nicht vorstellen wie egal es mir ist wie Du irgendetwas tust. Kauf dir ein Stück Kuchen und freu dich darüber das du so ein guter C- Programmierer bist.

Und warum werden wir gleich beleidigend?
Du hast Glück, keinen angemeldeten Account zu verwenden, sonst käme der in mein Killfile. Jedenfalls hast du gerade die Chance eliminiert, dass ich dir in diesem Thread nochmal helfe

Ja hoffentlich !!! Ich bitte sogar darum das du in gar keinem Thread mehr irgendwem hilfst. Lass es einfach.

Und Wutz hat vollkommen recht : Halt die Klappe.

*into the killfile it goes*.

Ob er da noch ruhig schlafen kann....

==>> Bitte jmd. den Thread schließen, hier ist alles gesagt. (Bis auf Mister D. war es auch alles hilfreich. ) .

volkard

pointer_frage schrieb:

Wahnsinn Alter, du bist so behämmert das es nur kracht. Checkst du es wirklich nicht ? Lesen... Typischer Fachidiot. Wie er im Buche steht.

Vorsicht! Damit beleidigst Du richtige Fachidioten wie mich.

pointer_frage schrieb:

==>> Bitte jmd. den Thread schließen, hier ist alles gesagt. (Bis auf Mister D. war es auch alles hilfreich. ) .

Schließen ist hier unüblich. Und diesen jetzt sicher nicht, denn es steht noch die spannende Frage offen nach weiterem Code, der arr != &arr ausnutzt.

Hallo volkard, ich würde dich NIE als FachIdioten bezeichnen. Ich glaube du weißt ziemlich genau was ich gemeint hatte