Zeiger auf Literal
-
das geht auch:
printf ("%d\n", 1[array[0]]); // geht printf ("%d\n", 1[0[array]]); // geht
-
Bashar schrieb:
[] ist linksassoziativ.
Und genau deswegen gehört da eine Typenprüfung hin!
Ich vermute fast, ich werde keine sinnvolle Begründung zu lesen bekommen, warum die fehlt. Es ist wohl so, weil es so ist, standardgewordener Hedonismus der C-Narzissten, sich in der selbstgeschaffenen Kryptik zu suhlen und das auch noch konsistent zu finden. Ist ja prinzipiell nix Neues, aber dieser Punkt war mir bislang unbekannt.
-
pointercrash() schrieb:
Bashar schrieb:
[] ist linksassoziativ.
Und genau deswegen gehört da eine Typenprüfung hin!
Logik? Wieso "genau deswegen"?
-
Bashar schrieb:
pointercrash() schrieb:
Bashar schrieb:
[] ist linksassoziativ.
Und genau deswegen gehört da eine Typenprüfung hin!
Logik? Wieso "genau deswegen"?
Wenn eine Zuordnung eindeutig sein könnte, soll sie es auch sein, um Fehler zu vermeiden. Die Logik, das kommutativ zu gestalten, ist grundsätzlich in Zweifel zu ziehen, weil sie dann hier scheitert
array[i] = 'c'; // Arrayzugriff i[array] = 'd'; // Arrayzugriff *(array+i) = 'e'; // direkte Pointerarithmetik, OK *(array-i) = 'f'; // direkte Pointerarithmetik, formal OK, für '-i' wird '+ abs(i)' verwendet // *(i-array) = 'g'; // [Error(ccom)] invalid '-' operands
Da steht viermal das Gleiche da, die fünfte Darstellung wird verweigert. Das ist keine konsistente Abbildung auf den zu erwartenden Ergebnisraum, also bedarf es da einer Regel, die es nicht gibt. Es ist ja keine echte mathematische Subtraktion, sondern Pointerarithmetik, die nur auf die Nase fällt, weil sie ausgerechnet hier über die Nichtkommutativität der Subtraktion stolpert. Das ist unstimmig. Weshalb die Subtraktion davor so geschluckt wird, ist sowieso der Hammer.
Spätestens nach frickys willkürlichen Chaoscode- Basteleien hätte Dir der Sinn einer Typprüfung einleuchtend sein müssen.
-
Aha, aber das hatte ich nicht gefragt.
-
[quote="pointercrash()"]
*(array-i) = 'f'; // direkte Pointerarithmetik, formal OK, für '-i' wird '+ abs(i)' verwendet
unfug. minus ist minus und braucht keine plus-bedeutung.
// *(i-array) = 'g'; // [Error(ccom)] invalid '-' operands
[/cpp]
logo. a-i ist ja auch was ganz anderes als i-a.
zum beispiel ist 13-8 was ganz anderes als 8-13.
-
ich hab grad mal versucht, das hier zu durchschauen: http://www.lysator.liu.se/c/ANSI-C-grammar-y.html#translation-unit
danach ist ein array-zugriff eine sogenannte 'postfix-expression' gefolgt von []. dummerweise kann diese eine 'primary-expression' sein, die wiederum nicht nur 'identifier' sondern auch 'konstante' sein darf. im innern der [] darf eine 'expression' sein, die alles mögliche darstellen kann (ich hab' die verzweigungen nicht genau verfolgt). es sieht's fast so aus, wie ein (wahrscheinlich unvermeidbarer) systembedingter fehler, weil sich da rekursionen bzw. schleifen eingeschlichen haben. es fehlen aber noch einschränkungen, wie's scheint. kennt sich hier jemand mit dieser darstellung aus?
-
Das hier ist interessant. Von ~frickys Quelle:
int check_type() { /* * pseudo code --- this is what it should check * * if (yytext == type_name) * return(TYPE_NAME); * * return(IDENTIFIER); */ /* * it actually will only return IDENTIFIER */ return(IDENTIFIER); }
EDIT: Bezieht sich aber wohl nur auf Deklarationen/Definitionen, sprich DCLs und hat mit dem Typchecking was in diesem Thread gewünscht wird nix zu tun.
-
volkard schrieb:
pointercrash() schrieb:
*(array-i) = 'f'; // direkte Pointerarithmetik, formal OK, für '-i' wird '+ abs(i)' verwendet
unfug. minus ist minus und braucht keine plus-bedeutung.
Ergebnis ist Ergebnis, die drei getesteten Compiler machen *(array+i) draus. Das Ganze ist ein Riesenunfug, da stimme ich Dir schon zu, aber den behaupte ich nicht, den produzieren meine Compiler.
volkard schrieb:
pointercrash() schrieb:
// *(i-array) = 'g'; // [Error(ccom)] invalid '-' operands
logo. a-i ist ja auch was ganz anderes als i-a.
zum beispiel ist 13-8 was ganz anderes als 8-13.Na klar, Du Held! Darin liegt ja die Inkonsistenz. Man leitet sich die Kommutativität von der mathematischen Addition ab und die Nichtkommutativität von der Subtraktion, daraus folgende Hirnrisse werden zurechtgehämmert. Dabei haben '+' (pointer+enum) und '+' (z.B. Int + Int) je nach Teilnehmer eigentlich gar nichts miteinander zu tun.
Das ist ganz schlimmer Schwachmatenkram, ganz miserabel durchdacht, in Pascal gäb's die Todesstrafe dafür.
Aber nicht mal 'ne gescheite Typenprüfung gibt's in C für subscript, das ist erbärmlich.
-
pointercrash() schrieb:
Ergebnis ist Ergebnis, die drei getesteten Compiler machen *(array+i) draus. Das Ganze ist ein Riesenunfug, da stimme ich Dir schon zu, aber den behaupte ich nicht, den produzieren meine Compiler.
Dann schmeiß deine tollen Compiler in die Tonne (oder alternativ, was wahrscheinlicher ist, deine Testmethode). Ein handelsüblicher gcc macht das richtig.
-
Bashar schrieb:
Dann schmeiß deine tollen Compiler in die Tonne (oder alternativ, was wahrscheinlicher ist, deine Testmethode).
Wer bist Du, mich deswegen persönlich anzugehen? Testen heißt Eintippen, Compilieren, Disassemblieren. Und glaub' mir, das kann ich immer noch.
Bashar schrieb:
Ein handelsüblicher gcc macht das richtig.
Abgesehen davon, daß GCCs selten im Handel zu erhalten sind :p , war auch ein GCC- Port darunter. Btw, was soll denn "richtig" sein? Mich interessiert auch weniger, was Compiler aus dem Käse machen, sondern warum er so dastehen darf.
Logisch wäre es, Argumente zur Pointerarithmetik nicht kommutativ zu erlauben und Typenprüfung zu betreiben, dann hätten wir die Sinnlosdebatte nicht.
-
pointercrash() schrieb:
volkard schrieb:
pointercrash() schrieb:
*(array-i) = 'f'; // direkte Pointerarithmetik, formal OK, für '-i' wird '+ abs(i)' verwendet
unfug. minus ist minus und braucht keine plus-bedeutung.
Ergebnis ist Ergebnis, die drei getesteten Compiler machen *(array+i) draus.
du musst dich täuschen. von pointern darf man auch was abziehen. sehr unwahrscheinlich, dass ein compiler das falsch macht.
pointercrash() schrieb:
Das ist ganz schlimmer Schwachmatenkram, ganz miserabel durchdacht, in Pascal gäb's die Todesstrafe dafür.
C ist nun mal schwach typisiert und hat ein paar kleinere macken, aber im grossen und ganzen ist es doch sehr brauchbar. ich finde i[array] gar nicht so schlimm, weil man's ja zu 100% vermeiden kann. auch wenn kein schwein erklären kann, aus welchem grund es i[array] überhaupt gibt.
-
pointercrash() schrieb:
Bashar schrieb:
Dann schmeiß deine tollen Compiler in die Tonne (oder alternativ, was wahrscheinlicher ist, deine Testmethode).
Wer bist Du, mich deswegen persönlich anzugehen?
der ist immer so griesgrämig, hat in seinem leben bestimmt viel schlimmes erlebt. mach dir nix draus.
-
~fricky schrieb:
*(array-i) = 'f'; // direkte Pointerarithmetik, formal OK, für '-i' wird '+ abs(i)' verwendet
du musst dich täuschen. von pointern darf man auch was abziehen. sehr unwahrscheinlich, dass ein compiler das falsch macht.
Nein, wirklich nicht, wobei zwei von Renesas sind und einer ein etwas angestaubter KPIT- GCC (brauch' ich aber noch, weil der als letzter COFF für meinen Debugger erzeugt).
~fricky schrieb:
C ist nun mal schwach typisiert und hat ein paar kleinere macken, aber im grossen und ganzen ist es doch sehr brauchbar.
Ja sicher, es bezieht seinen Gebrauchswert aus seiner Mächtigkeit, der Standardisierung und der Verbreitung. Aber wirklich "user-friendly" - ich weiß nicht.
~fricky schrieb:
ich finde i[array] gar nicht so schlimm, weil man's ja zu 100% vermeiden kann.
So nach "if it hurts, don't do it?". Wär' aber auch kein Blech gewesen, das schöner zu machen.
~fricky schrieb:
auch wenn kein schwein erklären kann, aus welchem grund es i[array] überhaupt gibt.
Früher hieß das, wenn's Dir hier nicht paßt, dann geh' doch 'rüber in den Osten, zu den Roten, den Kommunisten. Abgesehen von der seit 20 Jahren nicht mehr bestehenden Möglichkeit "rüberzumachen", wünsche ich mir eigentlich nur ein "besseres" C. C89/C99, wird es ein C09 geben? Aufräumen wär' vielleicht doch mal eine Idee.
-
pointercrash() schrieb:
Wer bist Du, mich deswegen persönlich anzugehen?
Entschuldige bitte, aber bevor ich annehme, dass gleich 3 Compiler buggy sind, denke ich an das naheliegendere.
[Ansonsten bin ich nicht immer griesgrämig, sondern nur jetzt gerade, und wenn ich über die Stränge schlage, tut es mir aufrichtig leid. Fricky ärgern tu ich natürlich sonst auch gerne :p]
Testen heißt Eintippen, Compilieren, Disassemblieren. Und glaub' mir, das kann ich immer noch.
Komisch, sowas ähnliches mach ich auch (halt gcc -S), und einmal steht da addl und einmal subl.
Mich interessiert auch weniger, was Compiler aus dem Käse machen, sondern warum er so dastehen darf.
Wenn du unbedingt willst, such ich dir das aus dem Standard raus, notfalls treib ich einen C89 auf. Aber einfach mal so die absolut einsichtigen Regeln der Pointerarithmetik anzuzweifeln ist schon ein ziemlich starkes Stück, dafür sollte man nicht den Standard bemühen müssen.
Du glaubst doch nicht im Ernst, dass das folgende Programm
int main() { int array[10]; int *p = array + 1; *(p-1) = 42; ... }
die 42 an Stelle 2 von 'array' hinschreibt.
(Das ist BTW nicht mein Testprogramm.)Logisch wäre es, Argumente zur Pointerarithmetik nicht kommutativ zu erlauben und Typenprüfung zu betreiben, dann hätten wir die Sinnlosdebatte nicht.
Man kann das auch einfach als Kuriosum am Rande hinnehmen und darüber lachen. Aber irgendwer hier musste ja eine "Sinnlosdebatte" lostreten :p
-
Aber die tollen Compiler gehören wirklich in die Tonne, wenn sie sowas machen. Und sie machen es bestimmt nicht. Da müßte ja der compilerbauer mit Absicht eine Fallunterscheidung einbauen, um diesen Unfug zu erreichen.
Vermutlich steht da nur add, weil nicht 1 gesubt wird, sondern 0xffffffff geaddet wird oder sowas.
-
pointercrash() schrieb:
~fricky schrieb:
*(array-i) = 'f'; // direkte Pointerarithmetik, formal OK, für '-i' wird '+ abs(i)' verwendet
du musst dich täuschen. von pointern darf man auch was abziehen. sehr unwahrscheinlich, dass ein compiler das falsch macht.
Nein, wirklich nicht, wobei zwei von Renesas sind und einer ein etwas angestaubter KPIT- GCC (brauch' ich aber noch, weil der als letzter COFF für meinen Debugger erzeugt).
so'n fehler würde sofort auffallen. compiler-programmierer pflegen auch buglisten. es würde sofort tonnen von protest-emails hageln, sollte sowas grundlegendes nicht funzen.
pointercrash() schrieb:
...wünsche ich mir eigentlich nur ein "besseres" C. C89/C99, wird es ein C09 geben? Aufräumen wär' vielleicht doch mal eine Idee.
ich müsste verdammt lange nachdenken, bis mir was einfallen würde, das mir wirklich an C wirklich fehlt. eins der prinzipien der c-standardisierer lautet ja: 'keep the spirit of C'(*). das verhindert schon mal, dass C so ein hässliches und kaputtes monster wird, wie seine grosse schwester. wenn du perfektionist bist, könntest du ADA nehmen. es gibt ja ADA front-ends, die C-code ausspucken, den man dann dem c-compiler seines vertrauens vorsetzen kann.
Sprit of C schrieb:
- Trust the programmer. Don’t prevent the programmer from doing what needs to be done.
- Keep the language small and simple.
- Provide only one way to do an operation.
- Make it fast, even if it is not guaranteed to be portable.
-
volkard schrieb:
Vermutlich steht da nur add, weil nicht 1 gesubt wird, sondern 0xffffffff geaddet wird oder sowas.
Asche über mein Haupt, Volkard hat mit seiner Vermutung recht, es wird tatsächlich das 2K addiert.
Aufgefallen ist mir das, als ich das Zeug mal wirklich im Emulator laufen gelassen hab', beim dritten Compiler war ich wohl schon so davon überzeugt, daß das alles Mist ist, daß ich das sub.w geflissentlich überlesen habe.Bashar schrieb:
[Ansonsten bin ich nicht immer griesgrämig, sondern nur jetzt gerade, und wenn ich über die Stränge schlage, tut es mir aufrichtig leid. Fricky ärgern tu ich natürlich sonst auch gerne :p
Wer nicht?
Gut, ich war ja auch ein bisserl pampig, sorry!
Bashar schrieb:
Komisch, sowas ähnliches mach ich auch (halt gcc -S), und einmal steht da addl und einmal subl.
Hab' meine Schlamperei schon gebeichtet!
Bashar schrieb:
Du glaubst doch nicht im Ernst, dass das folgende Programm ...
Ja, hat mich darauf gebracht, meinen Kram nochmal anzuschauen.
Bashar schrieb:
Man kann das auch einfach als Kuriosum am Rande hinnehmen und darüber lachen. Aber irgendwer hier musste ja eine "Sinnlosdebatte" lostreten :p
Kurios, ja. Aber über Behinderte zu lachen, ist politisch unkorrekt
~fricky schrieb:
ich müsste verdammt lange nachdenken, bis mir was einfallen würde, das mir wirklich an C wirklich fehlt. eins der prinzipien der c-standardisierer lautet ja: 'keep the spirit of C'(*). das verhindert schon mal, dass C so ein hässliches und kaputtes monster wird, wie seine grosse schwester. wenn du perfektionist bist, könntest du ADA nehmen. es gibt ja ADA front-ends, die C-code ausspucken, den man dann dem c-compiler seines vertrauens vorsetzen kann.
Also die Precompiler kranken daran, daß beim Debuggen der Bezug zur Ur- Source meist nicht erhalten bleibt (sh. Lightweight C++), so schlimm finde ich dann C auch wieder nicht, um darauf zu verzichten.
Vermissen tue ich bei C ja nichts, finde eher, daß C99 bereits überfrachtet ist. Und ich weiß nicht, was der Spirit meintSprit of C schrieb:
- Provide only one way to do an operation.
, weil ja Subscript so betrachtet eigentlich völlig überflüssig ist. Geister sind halt einfach schwer zu fassen ...
Sprit of C schrieb:
- Trust the programmer. Don’t prevent the programmer from doing what needs to be done.
- Keep the language small and simple.
- Provide only one way to do an operation.
- Make it fast, even if it is not guaranteed to be portable.