Hallo,
es ist schon pervers was mit C alles machbar ist.
Ich hab da mal den folgenden Code zusammengebastelt und der läuft unter
dem Dev-C++ Compiler. Nur blickt doch kein Schwein mehr sowas ;-) Für i
sollte übrigens am Ende 80 rauskommen.
Was habt ihr noch für Ideen wie man den Code noch "unverständlicher"
hinkriegt? ;-)
Gruß,
Thomas
#include <cstdlib>
#include <iostream>
using namespace std;
int main(int argc, char *argv[])
{
unsigned int* b,i=0,z=2,v=1;
unsigned int a[3][3]={0,8,6,4,2,9,7,3,5};
a[-10,3.141,2][-0.5486954E+12,1,1]=8;
b=&i;
i=5,9,5.5896410,6.59452,6,1,i++,i=i<=5<=7,i++,*b=char(-0xF8)+(unsigned
int)(~0xDE&(char)((*b+v[z[a]])<<2)),*b+='\'',i++;
printf("\ni=%i\n\n",i);
system("PAUSE");
return EXIT_SUCCESS;
}
Gast
#463533
International Obfuscated C Code Contest http://www.de.ioccc.org/years.html Schönes Beispiel: gavare.c
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
Gast
#463630
Versagt! Da kommt keine 80 raus ;-)
Gast
#463639
Oh Gott, bitte lass keine Perl Junkies diesen Thread entdecken ;D
@Stefan: Doch...80 ist korrekt. Wieso sollte das net so sein?
Gast
#463734
Was ist denn mit Perl? ;-)
$a=
"cpuu
\bmft p
\bg cff
\bs";$b
="po ui
\bf xbm
\bm";$c="
Ypv ublf p
\bof epxo qb
\btt ju bspvoe";
$a =~ s/\n//;$a =~
s/\s+/ /g; $b =~
s/\n// ; $b =~
s/\s+/ /g;$c =~
s/\n// ; $c =~
s/\s+/ /g;$a =~
y/b-z/a-z/;$b =~
tr/b-z/a-z/;$c =~
tr/b-z/a-z/ ; for(
$d=100;$d>0;$d--){
print"$d $a $b $d"
;print" $a,\n$c, "
;print($d-1);print
" $a $b.\n";} $x =
"cjc"; $y="dobbz";
$z="com";print"\n"
;print "- $x\@$y."
;print"$z \n\n";
http://www.99-bottles-of-beer.net/
Gast
#463770
Abartige Syntax :-) Oh wie schön ist Pascal (und Basic) ;-) Sigma n.
Gast
#463788
> i=5,9,5.5896410,6.59452,6,1,i++,i=i<=5<=7,i++,*b=char(-0xF8)+(unsigned
int)(~0xDE&(char)((*b+v[z[a]])<<2)),*b+='\'',i++;
Was bewirkt denn diese Komma-Schreibweise? Noch nie gesehen ^^
Stink normaler Komma-Operator Der Komma Operator wertet alle Teilasudrücke aus. Das Ergebnis des Komma Operators ist der am weitesten rechts stehende Ausdruck i = 5, 9, 5.589; ist also identisch mit i = 5.589; Die dazwischenliegenden Ausdrücke sind nur aufgrund ihrer Nebeneffekte (wenn überhaupt) interessant. Findest du in jedem C Buch.
Gast
#463965
Hehe...seltsam, noch nie gesehen! Macht IMHO aber auch kaum jemals Sinn bzw. gibt gefährlich unübersichtlichen Code. (Ausser für Variabelndeklarationen, dort kenne ich es.)
Gast
#464879
mann, da bleib ich lieber gleich bei assembler...
> Hehe...seltsam, noch nie gesehen! Macht IMHO aber auch kaum > jemals Sinn bzw. gibt gefährlich unübersichtlichen Code. Ganz genau. Die einzige Stelle wo man sowas unter Umständen benutzt ist hier: for( i = 0, j = 5, k = 8; i < 12; ++i, j = 2 * j ) > (Ausser für Variabelndeklarationen, dort kenne ich es.) Dort ist das Komma aber kein Kommaoperator :-)
Interessant, aber >Der Komma Operator wertet alle Teilasudrücke aus. Das Ergebnis >des Komma Operators ist der am weitesten rechts stehende Ausdruck wofür brauch man sowas?
> wofür brauch man sowas?
Wenn du mehrere Ausdrücke brauchst, aber nur eine
Expression zulässig ist.
for( i = 0, j = 5, k = 8; i < 12; ++i, j = 2 * j )
j = Relation ? j = 0, i = 5, k : 2 * m;
Aber wie Mr. Chip schon so treffend sagte:
gibt gefährlich unübersichtlichen Code.
Besonders lustig wird das Ganze in C++. Dort kann man den
Komma Operator auch noch überladen :-) Macht aber nicht
wirklich Sinn und es wird ausdrücklich eindringlich davor
gewarnt das jemals zu tun.
Aaaaah, ich verstehe. Das Komma da in deiner for-anweisung ist tatsächlich der gleiche Operator. Also der Operator führt alle Ausdrücke aus und gibt das Ergebnis des letzten Operators zurück (was bei deiner Anwendung mit dieser for-anweisung aber nebensächlich ist). Klingt logisch :-) Ma wieder wat jelernt.
Simon Küppers wrote: > Also der Operator führt alle Ausdrücke aus und gibt das Ergebnis des > letzten Operators zurück (was bei deiner Anwendung mit dieser > for-anweisung aber nebensächlich ist) Exakt. Bei dem ?: ist es dann allerdings nicht mehr nebensächlich > Ma wieder wat jelernt. Wie gesagt: Das for-Beispiel kommt manchmal vor. Vor allem im Inkrementteil sieht man das manchmal. Seltener, aber doch, im Initialisierungsteil. Das ?: Beispiel ist etwas konstruiert. In realem Code habe ich das so noch nie gesehen.
Gast
#465274
Hilfe ich stehe aufm Schlauch und das nicht undezent Problem: CVAVR using intern EEprom (Atmega32) Ich bekomme die Strings zwar ins Eeprom aber auslesen gelingt mir zur laufzeit nicht. Irgend wie klappt das mit den Zeigern auch nicht und mein Schatz ist schon sauer weil ich nicht auf die Matratze finde. Aber wie das so ist ein ungelöstes Dillemma läßt mich nicht schlafen ;-) assembler wäre ein Ausweg aber wintutrial und gvcc helfen mir nicht weiter. es muss mit CVAVR compatibel werden. Ziel String von Eeprom an UART bringen.
Gast
#465275
sorry fürs OT woolte eigentlich eigenes thema machen aber vielleicht gehts auch so ;-)
> Ich bekomme die Strings zwar ins Eeprom aber auslesen gelingt mir zur > laufzeit nicht. Irgend wie klappt das mit den Zeigern Zeig doch mal etwas Code her. Laut Handbuch sollte das recht einfach gehen. eeprom Variablen müssen globale Variablen sein. Du holst dir dann Zeichen für Zeichen vom EEprom in eine Zwischenvariable und von dort gehts weiter zur UART. Ich hab keinen CVAVR da, kann also nur nach dem gehen was ich im Handbuch sehe. Also: Was hast du konkret programmiert?
Gast
#465277
sorry den rechner musste ich schon schlafen schicken, da in dem zimmer unser weinachtsgasteinquartier ist. bin jetzt in Wz ausgewichen und da ist das nicht drauf
Gast
#465278
speichern geht per Compiler mit eeprom char dummy[]="Test" das funktioniert problemlos aber wiedesehen kann ichs nur wenn ich per ISP in EEprom schaue putchar, printf, sprintf etc können nur variablen aus flach und sram verarbeiten der versuch mit strcpy scheiterte ebenso wie die übergabe *str=*dummy
winne wrote: > > putchar, printf, sprintf etc können nur variablen aus flach und sram > verarbeiten der versuch mit strcpy scheiterte ebenso wie die übergabe > > > *str=*dummy# Das glaub ich. EEprom wird nun mal anders angesprochen als SRAM. Das kann strcpy aber nicht wissen. Daher sagte ich doch: du musst über Zwischenvariablen gehen, bzw. viele Funktionen selbst machen, wenn es von CVAVR dafür keine Unterstützung gibt. Für strcpy() könnte ich mir vorstellen, dass es eine eigene Variante dafür gibt, für printf() und sprintf() könnte es ein eigenes Formatier- zeichen dafür geben (Ist aber nur Spekulation). Als Beispiel mal ein Replacement für strcpy() eeprom char dummy[] = "Test"; void eeprom_strcpy( char* dest, eeprom char* src ) { while( *src ) { *dest = *src; dest++; src++; } *dest = '\0'; } Der entscheidende Unterschied besteht darin, dass src explizit als eeprom Pointer definiert ist. Damit kann dann die Funktion intern auf den richtigen Speicher zugreifen. Bevor du mit den Strings aus dem EEProm irgendwas machen kannst, musst du sie erst mal aus dem EEprom in das normale SRAM holen. > der versuch mit strcpy scheiterte ebenso wie die übergabe > *str=*dummy Letzters ist mir nicht klar. Was hast du da konkret gemacht?
Hallo Karl Heinz, erst einmal Danke für deine Antwort leider kam ich nicht früher dazu. Ich werde Deine Tips gleich testen und dann berichten. Eventuell hatt es ja tatsächlich mit verschiedenen pointerformaten zu tun da könnte mir deine Methode heraushelfen. Mfg Winne
Hallo K.H. leider mochte er auch diese Variante der Pointerverbiegerei nicht Hier die Lösung meines Rätsels aus den examples von CVAVR der Wald und die Bäume Beitrag "eeprom beispiele für cvavr" an alle anderen Nochmals Entschuldigung für's oT