Wieso geht das?

[Che]

Vielleicht steh ich heute auch auf der leitung, aber ich kapier nicht wieso das funktioniert:


int p1,p2;
p1 = Breite / 256;
p2 = Breite - p1 * 256;
Header[13] = p1;
Header[12] = p2;


Header ist ein Array von 18 Bytes:

BYTE Header[18];


Jetzt weise ich Header[13] bzw. Header[12] aber einen int zu, der, wenn ich richtig informiert bin, 4 Bytes braucht. Ich krieg keine Fehlermeldung und der Code funktioniert so wie er sollte. Ich müsste doch eine Fehlermeldung kriegen, oder zumindest müsste irgendetwas passieren wenn ich diesen Code ausführe ??? (->fehlermeldung, schutzverletzung, irgendetwas, aber der code dürfte nicht funktionieren)

Bitte um Aufklärung.

[zeckensack]

Die ints werden automatisch zu bytes abgeschnitten, wenn sie ins Array geschrieben werden sollen.

Eigentlich sollte der Compiler eine Warnung ausspucken, die dich darauf hinweist daß du gefälligst selbst die Typumwandlung ausführen sollst.

[Exxtreme]

Jepp. Wenn du den Integern einen Wert grösser 255 zuweist dann klappt dieser Trick nicht mahr.

[Che]

So, nach 2 Tagen ohne Internet bin ich wieder da, und darf euch darüber in Kenntnis setzen, dass ich da selber auch schon draufgekommen bin. An dem Tag an dem ich diese Frage hier gepostet hab war mein Gehirn wohl etwas verwuzelt, und da ich vieeeel zu faul war eingehender darüber nachzudenken, hab ich euch dieses Problem aufs Auge gedrückt:D (Danke übrigens für Antwort)
Ich hab aus irgendeinem Grund gedacht ich hätts hier mit dynamischem Speicher zu tun, dann wärs nämlich ein Problem gewesen:

BYTE *Header;
Header = (BYTE*)malloc(sizeof(BYTE));
int x=5;
Header=&x


Böse: 3 Bytes unkontrollierter Speicherpfusch.

Was mich allerdings trotzdem wundert ist dass ich keine Warnung "Conversion from x to y: Possible loss of data" krieg, wie von zeckensack schon angesprochen.???


Mögliche Lösung dieses wahrlich wundersamen Umstands: Ich benutze einen MS-Compiler;D

[Demirug]

Originally posted by Che
So, nach 2 Tagen ohne Internet bin ich wieder da, und darf euch darüber in Kenntnis setzen, dass ich da selber auch schon draufgekommen bin. An dem Tag an dem ich diese Frage hier gepostet hab war mein Gehirn wohl etwas verwuzelt, und da ich vieeeel zu faul war eingehender darüber nachzudenken, hab ich euch dieses Problem aufs Auge gedrückt:D (Danke übrigens für Antwort)
Ich hab aus irgendeinem Grund gedacht ich hätts hier mit dynamischem Speicher zu tun, dann wärs nämlich ein Problem gewesen:

BYTE *Header;
Header = (BYTE*)malloc(sizeof(BYTE));
int x=5;
Header=&x


Böse: 3 Bytes unkontrollierter Speicherpfusch.

Was mich allerdings trotzdem wundert ist dass ich keine Warnung "Conversion from x to y: Possible loss of data" krieg, wie von zeckensack schon angesprochen.???


Mögliche Lösung dieses wahrlich wundersamen Umstands: Ich benutze einen MS-Compiler;D

Du machst dir beim dynamischen Speicher wegen 3 Byte gedanken? Dann sag ich dir besser nicht wie viel overhead ein dynamischer Speicherblock schon erzeugt.

Das du keine Warnung bekommst könnte daran liegen das der Warnlevel zu hoch eingestellt ist.

[Che]

Overhead kann ja ruhig sein, da weiß ich sicher DASS er zu einem Speicherblock gehört. In meinem Beispiel mach ich mir Sorgen weil ich da in einen Speicherbereich schreib der NIRGENDS hingehört, oder noch schlimmer, der zu einem anderen Speicherblock gehört. Und das ist nicht gut. ;)

Warnlevel einstellen? Wo geht das denn? (VC++ 6.0)

btw: Wieviel Overhead erzeugt denn so ein dynamischer Speicher?

[Xmas]

Originally posted by Che

BYTE *Header;
Header = (BYTE*)malloc(sizeof(BYTE));
int x=5;
Header=&x


Böse: 3 Bytes unkontrollierter Speicherpfusch.
Wohl ein Vertipper, oder?
Header ist ein Pointer auf ein BYTE. &x ist die Adresse von x. Nach dieser Zuweisung zeigt Header auf das niedrigste Byte von x (Intel-Architektur). Den einzigen "Speicherpfusch" den du hier hast ist dass der per malloc angeforderte Speicherbereich nicht mehr freigegeben werden kann da die Adresse verloren geht.

Allerdings sollte trotzdem eine Compilerwarnung erscheinen. Warnlevel stellst du ein in Projekt|Einstellungen(Alt+F7)|C/C++, Kategorie Allgemein

[Che]

Originally posted by Xmas

Wohl ein Vertipper, oder?
Header ist ein Pointer auf ein BYTE. &x ist die Adresse von x. Nach dieser Zuweisung zeigt Header auf das niedrigste Byte von x (Intel-Architektur). Den einzigen "Speicherpfusch" den du hier hast ist dass der per malloc angeforderte Speicherbereich nicht mehr freigegeben werden kann da die Adresse verloren geht.

Allerdings sollte trotzdem eine Compilerwarnung erscheinen. Warnlevel stellst du ein in Projekt|Einstellungen(Alt+F7)|C/C++, Kategorie Allgemein

:sulkoff: Da hast du allerdings recht *schäm*
Also, dann probier ichs nochmal:

BYTE *Header;
Header = (BYTE*)malloc(sizeof(BYTE));
int x=5;
*Header=x


(Ich komm schon noch zu meinem speichercrash :devil: )

[Exxtreme]

Originally posted by Che


:sulkoff: Da hast du allerdings recht *schäm*
Also, dann probier ichs nochmal:

BYTE *Header;
Header = (BYTE*)malloc(sizeof(BYTE));
int x=5;
*Header=x


Sieht schon besser aus. Weis mal x einen Wert >255 zu. ;)

Originally posted by Che

(Ich komm schon noch zu meinem speichercrash :devil: )
Speichercrash? Gerne. Welchen hätten Sie gerne?

[Che]

Originally posted by Exxtreme

Sieht schon besser aus. Weis mal x einen Wert >255 zu. ;)



Macht denn das einen Unterschied? Ein int braucht 32 bit, egal welchen Wert er speichert. Oder bin ich da falsch informiert?

Speichercrash: Vor kurzem meinen Compi mit einem 2. 128MB Riegel beglückt. Die alten 128 MB kennen mich ja schon und haben gebührenden Respekt vor mir, aber die neuen muss ich noch ein bisschen einschüchtern...:naughty:

[Exxtreme]

Originally posted by Che


Macht denn das einen Unterschied? Ein int braucht 32 bit, egal welchen Wert er speichert. Oder bin ich da falsch informiert?

Jein. Ein int unter DOS hat 16 Bit gebraucht... zumindest bei Borland C. Für 32 Bit gab es dann einen long int. Ein byte hat aber nur 8 Bit, deswegen habe ich geschrieben x einen Wert > 255 zuzuweisen.
;)
Originally posted by Che
Speichercrash: Vor kurzem meinen Compi mit einem 2. 128MB Riegel beglückt. Die alten 128 MB kennen mich ja schon und haben gebührenden Respekt vor mir, aber die neuen muss ich noch ein bisschen einschüchtern...:naughty:
Brauchst du jetzt Beispiele für einen Speicherabschuss oder nicht?

[Che]

Originally posted by Exxtreme

Jein. Ein int unter DOS hat 16 Bit gebraucht... zumindest bei Borland C. Für 32 Bit gab es dann einen long int. Ein byte hat aber nur 8 Bit, deswegen habe ich geschrieben x einen Wert > 255 zuzuweisen.
;)


Ich versteh nicht ganz was der Wert, den ich x zuweise, zu sagen hat. Auch wenn x den Wert 5 hat, ist es doch ein int und braucht 4 byte. Wenn ich also an eine Byte-Speicherstelle (1 byte) einen int-Wert schreibe (4 byte), dann habe ich auf jeden Fall Mist gebaut.

Originally posted by Exxtreme
Brauchst du jetzt Beispiele für einen Speicherabschuss oder nicht?

Immer her damit...hrhrhr

[Exxtreme]

Originally posted by Che


Ich versteh nicht ganz was der Wert, den ich x zuweise, zu sagen hat. Auch wenn x den Wert 5 hat, ist es doch ein int und braucht 4 byte. Wenn ich also an eine Byte-Speicherstelle (1 byte) einen int-Wert schreibe (4 byte), dann habe ich auf jeden Fall Mist gebaut.

Schau dir dein Code-Beispiel nochmal genau an. Und ich sage, daß du im Endeffekt doch einen int dem byte zuweist.
Originally posted by Che
Immer her damit...hrhrhr
Ok, hier habe ich was Fieses. Unter DOS crasht das garantiert:


void SmashTheSystem()
{
int iTest[10000];
SmashTheSystem();
}

void main()
{
SmashTheSystem();
}

[Che]

Originally posted by Exxtreme

Schau dir dein Code-Beispiel nochmal genau an. Und ich sage, daß du im Endeffekt doch einen int dem byte zuweist.



Eben deswegen ist es ja gefährlich egal welchen Wert der int hat.

Hm, kanns sein dass wir hier von verschiedenen Dingen reden? Also ich hab nicht verstanden, was der Wert den ich x zuweise, zur Sache beizutragen hat.

Originally posted by Exxtreme
Weis mal x einen Wert >255 zu.



Wer hat den schönsten(;)) Code um den PC abzumurksen? Exxtremes Beispiel ist schonmal nicht schlecht. (Wie lang dauerts inter Win bis er isch aufregt? *Ausprobier*)

[Nasenbaer]

Originally posted by Exxtreme
Speichercrash? Gerne. Welchen hätten Sie gerne?

Das erinnert mich an meine lustigen Speicher-Zuklopp-Programme, die ich immer dann schreibe, wenn die PCs in der Schule mal wieder nix anderes hinbekommen, weil kleine Kinder irgendwelchen Unfug damit machen.



LONGLONG *Test;
while(true)
{
Test = new LONGLONG;
}


Hervorragend gegen Langeweile und zumindest unter Win98 auch ein Fest für die Augen, wenn sich die GUI auflöst. :D
Die Speicher-Anzeige des WInXP/2k Taskmanagers bastelt auch gleich das passende Diagram. *gg*

Mfg Nasenbaer

[Che]

Originally posted by Nasenbaer


Das erinnert mich an meine lustigen Speicher-Zuklopp-Programme, die ich immer dann schreibe, wenn die PCs in der Schule mal wieder nix anderes hinbekommen, weil kleine Kinder irgendwelchen Unfug damit machen.



LONGLONG *Test;
while(true)
{
Test = new LONGLONG;
}


Hervorragend gegen Langeweile und zumindest unter Win98 auch ein Fest für die Augen, wenn sich die GUI auflöst. :D
Die Speicher-Anzeige des WInXP/2k Taskmanagers bastelt auch gleich das passende Diagram. *gg*

Mfg Nasenbaer

Hehe:D, das ist gut. 200Mb in 1 sek. verbraten. Abstürzen tut er aber nicht bei mir(Win98)
Habr ihr auch was richtig böses ? (Ihr wisst schon wie ichs mein ;))

[zeckensack]

Weiß nicht, ob's geht, aber versuch das mal (in einem Windows-Programm):

#include <stdlib.h>

<...>


while (1)
{
unsigned int watumba=rand()&0xFFFF;
HDC screen=GetDC(NULL);
SetDeviceGammaRamp(screen,(void*)watumba);
ReleaseDC(0,screen);
}

[GloomY]

@Che: C macht eine implizierte Typenkonvertierung. D.h. wenn du einem BYTE Wert einen Integer Wert zuweisst und dieser in den Wertebereich des BYTE Typs passt, dann geht das ohne Probleme.

Aber wenn der Wertebereich des Byte Typs überschritten wird ( > 255), dann wird keine implizite Typenkonvertierung vorgenommen, so dass der (8 Bit großen) BYTE-Speicherstelle ein (normalerweise) 32 Bit großer Wert zugewiesen wird. Also werden die nächsten 24 bit hinter dem Byte Wert überschrieben, was wahrscheinlich zu einer Schutzverletzung führt (muss aber nicht).

Ja, mit Zeigern kann man allerhand "schöne Dinge" machen :D

[zeckensack]

Originally posted by GloomY
@Che: C macht eine implizierte Typenkonvertierung. D.h. wenn du einem BYTE Wert einen Integer Wert zuweisst und dieser in den Wertebereich des BYTE Typs passt, dann geht das ohne Probleme.

Aber wenn der Wertebereich des Byte Typs überschritten wird ( > 255), dann wird keine implizite Typenkonvertierung vorgenommen, so dass der (8 Bit großen) BYTE-Speicherstelle ein (normalerweise) 32 Bit großer Wert zugewiesen wird. Also werden die nächsten 24 bit hinter dem Byte Wert überschrieben, was wahrscheinlich zu einer Schutzverletzung führt (muss aber nicht).

Ja, mit Zeigern kann man allerhand "schöne Dinge" machen :D Knapp daneben ;)

Die Typkonversion wird immer durchgeführt. Wenn der Wert zu groß ist, werden die überzähligen Bits einfach abgeschnitten (ie Datenverlust).

Alsoubyte b;
ubyte* p=&b;
uint i=5;
*p=i; //b=5
i=273; //273=256+17
*p=i; //b=17

[GloomY]

Originally posted by zeckensack
Knapp daneben ;)Mist ;)
Originally posted by zeckensack
Die Typkonversion wird immer durchgeführt. Wenn der Wert zu groß ist, werden die überzähligen Bits einfach abgeschnitten (ie Datenverlust).Heißt das, daß es im obigen Beispiel auch für Werte > 255 zu keiner Schutzverletzung kommt?

[zeckensack]

Originally posted by GloomY
Heißt das, daß es im obigen Beispiel auch für Werte > 255 zu keiner Schutzverletzung kommt? Genau das heißt es :)

[Nasenbaer]

Originally posted by Che


Hehe:D, das ist gut. 200Mb in 1 sek. verbraten. Abstürzen tut er aber nicht bei mir(Win98)
Habr ihr auch was richtig böses ? (Ihr wisst schon wie ichs mein ;))

Entweder virtuellen Speicher ausmachen oder warten bis der ausgeschöpft ist. Folgender Code macht das noch besser.


struct fies
{
LONGLONG Test[100];
}

<...>

fies Dings;
while(true)
{
Dings = new fies;
}

Auch ganz wichtig bei der Programmierung sind die telling names bzw sprechende Bezeichner. =)

P.S. werd ich auch mal testen. *gg*

MFg Nasenbaer

[Che]

Originally posted by zeckensack
Genau das heißt es :)

Hm, dann ist mein "Problem" ja gar keins...Ich dachte immer da muss man aufpassen und darf einen Pointer der auf ein Byte zeigt nicht als einen Pointer der auf ein Int zeigt interpretieren/verwenden, weil man sonst 3 bytes "zuviel" hat. (Jetzt verstehe ich auch was Exxtreme die ganze Zeit mit >255 gemeint hat) Aber wenn das überzählige einfach abgeschnitten wird...
Wo bleibt denn da der Spass? ;)

[Che]

Originally posted by zeckensack
Weiß nicht, ob's geht, aber versuch das mal (in einem Windows-Programm):

#include <stdlib.h>

<...>


while (1)
{
unsigned int watumba=rand()&0xFFFF;
HDC screen=GetDC(NULL);
SetDeviceGammaRamp(screen,(void*)watumba);
ReleaseDC(0,screen);
}

Macht bei mir gar nichts...Muss ein Fenster schon exisitieren wegen HDC und SetDeviceGammaDings, weil ich habs einfach in eine leere winmain reingepastet.

[Che]

Originally posted by Nasenbaer
Auch ganz wichtig bei der Programmierung sind die telling names bzw sprechende Bezeichner. =)


;D :D :lol: :rofl:
Ich werds mir merken

[zeckensack]

Originally posted by Che


Macht bei mir gar nichts...Muss ein Fenster schon exisitieren wegen HDC und SetDeviceGammaDings, weil ich habs einfach in eine leere winmain reingepastet. Braucht kein Fenster.

Das sollte eigentlich früher oder später den Grakatreiber abschießen (Schutzverletzung), oder zumindest interessante Farben auf den Bildschirm zaubern :|

1)Wie gesagt, ist nicht getestet. Kommt vielleicht auch auf die Graka an, ob SetDeviceGamma überhaupt etwas macht.

2)Versuch auch mal ruhig
uint watumba=0;
Das müsste schneller zum Erfolg führen :cop:

[Che]

MSDN says:

SetDeviceGammaRamp succeeds only for devices with drivers that support downloadable gamma ramps in hardware.

Scheint meine Voodoo5 nicht zu können.