Nullpointer-Frage

lex schrieb:

> Bedeutet das, NULL_PTR ist hier garkein Nullpointer im C-Sinne?
> Sondern ein Zeiger auf die Adresse 0x00?

Ja, das bedeutet es.

> Kommen allerdings Bibliotheksfunktionen ins Spiel die einen "echten"
> Nullpointer zurückgeben wirds aber kritisch, oder?

Sagen wir mal so: in allen praktisch relevanten Fällen auf heutigen
Maschinen nicht, da der Nullzeiger wirklich auch der Zahl 0
entspricht.  Ein standardgerechtes Programm sollte aber nicht
versuchen, einen Nullzeiger selbst zu definieren, sondern entweder
wirklich auf 0 vergleichen (dann muss sich der Compiler oder die
Bibliothek ggf. um eine Umwandlung des Bitmusters kümmern, falls eine
exotische Zielmaschine sowas benötigt), oder die Konstante NULL
benutzen, die bspw. von <stdlib.h> oder <stdio.h> zur Verfügung
gestellt werden muss.

Charlie schrieb:
>> Ja, das bedeutet es.
>
> Nein!

Hatte Sven doch schon ausreichend klargestellt.

Da bin ich beim AVR 'mal auf die Nase gefallen. Ich hatte Zeiger auf 
Werte im EEPROM diese und - vorsichtig wie ich bin - vor Benutzung auf 
NULL getestet. Nur fängt der Adressbereich für EEPROM halt bei 0 an...

> Das ist egal, C kennt keinen Adressbereich. Genau aus diesem Grund ist
> '(void*)0' (also NULL) nicht auch identisch mit Adresse 0.

???

Sondern?
Wie willst Du einen void-Zeiger auf die Adresse 0L von NULL 
unterscheiden?

Sven P. schrieb:

> Das ist egal, C kennt keinen Adressbereich. Genau aus diesem Grund ist
> '(void*)0' (also NULL) nicht auch identisch mit Adresse 0.

Konzeptionell.

Als Bitmuster allerdings auf einem AVR letzten Endes schon.

Und genau da liegt auch das Problem mit dieser ganze 
Null-Pointer-Konstant Idee. Als Idee nicht schlecht, aber in der Praxis 
bringts nix, denn irgendeinen Wert wird man immer als die 
Null-Pointer-Konstante vereinbaren, der mit der für die spezielle CPU 
typischen Pointergröße prinzipiell darstellbar ist. Und damit hat man 
auch immer das Problem, dass dieser Wert in der Praxis regulär vorkommen 
könnte. Die Idee, dass der Wert der Null-Pointer-Konstante dergestalt 
ist, dass er nicht als regulärer Pointerwert auf dieser speziellen 
Hardware nicht auch vorkommen kann, ist zwar nett gedacht, in der Praxis 
aber nicht ohne zusätzliche Hilfsmittel (wie zb 1 Byte mehr als die 
normale Adressierung auf dieser Maschine verlangt) durchführbar. Das der 
Adresswert 0 für die Null-Pointer-Konstante gut funktioniert, ist mehr 
der Tatsache geschuldet, dass in der überwiegenden Mehrzahl der Fälle 
die Speicheradresse 0 vom Runtime-System sowieso nicht benutzbar ist 
(weil da zb das Betriebssystem irgendwelche Werte liegen hat und der 
Memory Allokierer diese Adresse niemals liefern wird) als das es der 
Tatsache geschuldet ist, dass die Idee hinter dieser 
Null-Pointer-Konstante so genial wäre. Hier ist man IMHO weit über das 
Ziel hinausgeschossen, ohne tatsächlich etwas zu erreichen.

Karl Heinz Buchegger schrieb:

> Null-Pointer-Konstant Idee. Als Idee nicht schlecht

Muss mich korrigieren.
Das ist noch nicht mal als Idee besonders gut.
Wobei Stroustrup die Idee in C++ IMHO noch weiter vermurkst hat.
In C ist wenigstens ein
#define NULL ((void*)0)
zugelassen. Wohlgemerkt: zugelassen. D.h. das ist nichts womit ich als 
Programmierer rechnen kann.
In C++ ist es noch nicht mal das. Was dann zu so seltsamen Blüten 
treibt, wie diese hier

1

void foo( char* str )

2

{

3

  ...

4

}

5

6

void foo( double val )

7

{

8

  ...

9

}

10

11

int main()

12

{

13

  foo( NULL );

14

}

Preisfrage: welche Funktion wird aufgerufen?
Antwort: die Version, die das double Argument nimmt. Und dabei hab doch 
extra wunderschön NULL benutzt um anzudeuten, dass ich hier einen 
Pointer-Kontext habe. Entschärfen lässt sich das ganze nur, indem ich 
selbst die vermeintliche Null-Pointer-Konstante explizit nochmals in 
einen Pointer caste

1

int main()

2

{

3

  foo( (char*)NULL );

4

}

Sinnig ist das nicht gerade.
Und das bei einer Sprache, die eigentlich die schlimmsten C Fallstricke 
'ausmerzen' wollte. Denn auch in C kann mich dieses Problem beißen: bei 
variadischen Funktionen. Aber die sind, abgesehen von printf, eher 
selten.

Peter II schrieb:
> Karl Heinz Buchegger schrieb:
>> In C++ ist es noch nicht mal das. Was dann zu so seltsamen Blüten
>> treibt, wie diese hier
>
> gibt es aus dem Grund nicht in C++ das nullptr?

Ja. In C++09.
Also seit rund 4 Jahren :-)

Nicht schlecht für ein Problem, welches in 30 Jahren für unzählige 
schlaflose Nächte verantwortlich war.

Alles was Stroustrup 1979 hätte tun müssen, wäre zu definierten, dass in 
C++ NULL immer und überall als
#define ((void*)0)
zu definieren ist und das Problem wäre keines mehr gewesen.

Matthias Lipinsky schrieb:
>>Preisfrage: welche Funktion wird aufgerufen?
>
> Lässt sowas der Compiler zu? Zwei identische Funktionen bzw.
> Funktionsnamen?

C++

C++ hat einige Altlasten von C geerbt. Und in vielen Fällen tatsächliche 
Verbesserung gebracht.
Aber hier hat BS IMHO danebengehauen.
Ich teile seine Abneigung für Makros in C++. Aber die Verwendung von 
NULL dadurch einzudämmen (weil es ein Makro ist, igitt), dass man

  if( ptr == 0 )

möglichst ohne Cast eintippbar macht, war der falsche Weg. Denn 
ironischerweise musste er in die Sprachdefinition hier eine Ausnahme für 
Pointeroperationen in denen das Integer-Literal 0 vorkommt, einführen, 
damit das überhaupt syntaktisch korrekt wird :-)

Matthias Lipinsky schrieb:
>>nein nicht bei C++
>
> Ah ok.
>
>
>>das sind normale überladungen mit anderer signatur.
>
> Es gilt dann wohl immer die letzte Definition?

No.
Es gilt die Funktion, deren Signatur am besten zu den Datentypen der 
Argumente an der Aufrufstelle passt (kurz zusammengefasst. Das ganze 
Thema ist bei Klassenhierarchien etwas komplexer - Stichwort: 
König-Lookup - aber im Endeffekt läuft es darauf hinaus, dass aus einer 
Menge von Kandidaten diejenige Funktion ausgewählt wird, bei der am 
wenigsten Konversionen der Argumentdatentypen des Aufrufes notwendig 
sind)

Matthias Lipinsky schrieb:
>>das sind normale überladungen mit anderer signatur.
>
> Es gilt dann wohl immer die letzte Definition?

Nein, die die "passt".

1

void print ( const char * str );

2

void print ( int num );

Mit print("Hallo") wird die erste Funktion aufgerufen, mit print(42) die 
zweite.

Sven P. schrieb:
> Karl Heinz Buchegger schrieb:
>> Preisfrage: welche Funktion wird aufgerufen?
>
> Garkeine, der Aufruf mit '0' als Argument ist nicht eindeutig und muss
> zum Compiler-Fehler führen...


OK.
Hab ich nicht bedacht.
Gut. Mach aus dem double einen int und gleiche Frage.

Sven P. schrieb:
> Karl Heinz Buchegger schrieb:
>> In C ist wenigstens ein
>> #define NULL ((void*)0)
>> zugelassen. Wohlgemerkt: zugelassen. D.h. das ist nichts womit ich als
>> Programmierer rechnen kann.
> Auf was kann man sich denn hier nicht verlassen?

variadische Funktionen, die eine ungecastete NULL nicht als Pointer 
übernehmen sondern als int.

Ist sizeof(int) != sizeof(void*), dann hast du Ärger.

Karl Heinz Buchegger schrieb:
> Aber die Verwendung von
> NULL dadurch einzudämmen (weil es ein Makro ist, igitt), dass man
>
>   if( ptr == 0 )
>
> möglichst ohne Cast eintippbar macht, war der falsche Weg.

Ja, er hätte es ja in der Hand gehabt, NULL als reserviertes Wort
einzuführen.  Dann muss man das nicht als Makro auflösen, sondern
der Compiler bildet es direkt in seinen Syntaxbaum ab.

Sven P. schrieb:

> Ein Zeiger auf NULL, also etwa '(void*)0' ist immer verschieden von
> allen anderen gültigen Zeigern. Auch auf Maschinen und Prozessoren, bei
> denen der Speicher ab '0' gezählt wird.
>

Das läuft jetzt irgendwie auf die m.E. sehr philosophische Diskussion 
hinaus, ob dasselbe etwas anderes ist, wenn man es nur anders nennt.

In meiner Welt ist NULL - wie jeder andere Zeigertyp, der den Wert 0L 
hat - ein Zeiger auf die Adresse 0, der sich - solange die Maschine es 
zulässt (und viele tun das) - dereferenzieren - mit dem sich also 
"arbeiten" - läßt.

Daß man Zeiger mit diesem Wert (der selten genug tatsächlich benötigt 
wird) dazu benutzen kann, um bestimmte (Sonder-/Fehler-) Situationen zu 
kennzeichnen, steht dem keinesfalls entgegen, finde ich.Genausogut hätte 
man auch MAXINT verwenden können, aber die Erfinder fanden 0L aus 
irgendwelchen Gründen halt praktischer.

Markus F. schrieb:
> Genausogut hätte
> man auch MAXINT verwenden können, aber die Erfinder fanden 0L aus
> irgendwelchen Gründen halt praktischer.

Der Grund ist sehr einfach.
Weil man Pointer dann in einem boolschen Kontext benutzen kann, ohne 
irgendwelche Sonderfälle, was wiederrum sehr praktisch beim Abfragen auf 
gültig/ungültig ist.

  if( ptr )


Das ist schon ok.


>> Ein Zeiger auf NULL, also etwa '(void*)0' ist immer verschieden von
>> allen anderen gültigen Zeigern. Auch auf Maschinen und Prozessoren, bei
>> denen der Speicher ab '0' gezählt wird.
>>
>
> Das läuft jetzt irgendwie auf die m.E. sehr philosophische Diskussion
> hinaus, ob dasselbe etwas anderes ist, wenn man es nur anders nennt.

Das seh ich auch so.
Denn in der Praxis ist diese Vorgabe nicht oder nur mit enormen 
Resourcenverbrauch durchführbar. Das ist wie ein spezieller Wert für 
int, der von allen mit int darstellbaren Werten verschieden sein soll. 
In der Praxis nicht machbar.

Jörg Wunsch schrieb:
> Karl Heinz Buchegger schrieb:
>> Aber die Verwendung von
>> NULL dadurch einzudämmen (weil es ein Makro ist, igitt), dass man
>>
>>   if( ptr == 0 )
>>
>> möglichst ohne Cast eintippbar macht, war der falsche Weg.
>
> Ja, er hätte es ja in der Hand gehabt, NULL als reserviertes Wort
> einzuführen.  Dann muss man das nicht als Makro auflösen, sondern
> der Compiler bildet es direkt in seinen Syntaxbaum ab.

Und genau so ist es dann ja letztenedes auch gekommen :-)
Nur 30 Jahre und Milliarden von Lines of Code zu spät.

jack schrieb:
> Und wie würde ich bei meinem Atmel zB auf die Adresse 0 zugreifen?
>
> Char *ptr = 0;
> DoSomething(*ptr);
>
> So?

Ja.
Bei den AVR Compilern hat die Null-Pointer-Konstante auch tatsächlich 
alle Bits auf 0.

jack schrieb:
> ein Zeiger auf die bei AVRs gültige Adresse 0x00
Im Prinzip ja, allerdings liegt dort das Register R0, es sit also 
vermutlich keine gute Idee überhaupt dorthin direkt zu schreiben auch 
wenn es möglich wäre, ich denke nicht das der Compiler erkennt das du 
ihm gerade eines seiner Register überbretzelst.

Und genau das ist doch der Punkt: Ich arbeite doch (hoffentlich) mit vom 
Compiler verwalteten Variablen, wenn nicht (wie beim EEPROM der oben 
angesprochen wurde) kann ich mich auch nicht auf die "Null-Pointer" 
Konvention verlassen oder muss mir was anderes ausdenken.

jack schrieb:
> Karl Heinz Buchegger schrieb:
>> Ja.
> Danke.
>
> Mit der Antwort wär ich glücklich gewesen, aber...
>> Bei den AVR Compilern hat die Null-Pointer-Konstante auch tatsächlich
>> alle Bits auf 0.
> ...verwirrt mich jetzt.
>
> Hat das was mit meiner Frage zu tun?
> Nachdem was ich hier gelesen habe ist:
> void *ptr = 0;     ein NULL-Pointer
> char *ptr = 0;     ein Zeiger auf die bei AVRs gültige Adresse 0x00
>
> Dennoch sind doch im zweiten Fall auch alle Bits auf 0, richtig?

genau.

> Nur durch die Deklaration mit void* wird Ersteres vom Compiler als
> NULL-Pointer interpretiert.

:-)
Um die Verwirrung aufzulösen.
Der C-Standard sagt nichts dazu, welchen konkreten Typ der Pointer haben 
muss. Ob der ein void* oder ein char* ist, spielt überhaupt keine Rolle. 
Es ist die reine Zuweisung von 0 an einen Pointer, die den Compiler dazu 
veranlasst, die 0 (!) als Null-Pointer-Konstante anzusehen und 
gegebenfalls diese 0 durch ein anderes Bitmuster auszutauschen. Die 0, 
und ihre Verwendung in einem Pointer-Kontext ist der springende Punkt!

Aber auf dem AVR hat die Null-Pointer-Konstante ebenfalls den Zahlenwert 
0. So wie auf den meisten Systemen. Ich kenne eigentlich kein System, 
bei dem das anders wäre.

Karl Heinz Buchegger schrieb:
> Wobei Stroustrup die Idee in C++ IMHO noch weiter vermurkst hat.

Das dürfte damit zusammenhängen, dass C++ keine cast-freie Konvertierung 
von void* nach sonstwas* zulässt. Das würde nämlich allzu leicht das 
ganze Typenkonzept von Klassen aushebeln, insbesondere bei multiple 
inheritance (da wird ggf. die Adresse umgerechnet).

Richtiger wäre allerdings ein nullptr gewesen.

Karl Heinz Buchegger schrieb:
> Aber auf dem AVR hat die Null-Pointer-Konstante ebenfalls den Zahlenwert
> 0. So wie auf den meisten Systemen. Ich kenne eigentlich kein System,
> bei dem das anders wäre.

Heute nicht mehr. Gab es aber. Bei den Transputern war der Adressbereich 
mit Vorzeichen realisiert, beim 16-Bitter T212 also -0x8000...+0x7FFF. 
Die 0 folglich mitten drin.

A. K. schrieb:
> Karl Heinz Buchegger schrieb:
>> Aber auf dem AVR hat die Null-Pointer-Konstante ebenfalls den Zahlenwert
>> 0. So wie auf den meisten Systemen. Ich kenne eigentlich kein System,
>> bei dem das anders wäre.
>
> Heute nicht mehr. Gab es aber. Bei den Transputern war der Adressbereich
> mit Vorzeichen realisiert, beim 16-Bitter T212 also -0x8000...+0x7FFF.
> Die 0 folglich mitten drin.


Sachen gibts :-)

Im Ernst.
Im C-Standard sind einige Anachronsimen enthalten, die früher mal 
relevant waren, aber schon seit einiger Zeit komplett irrelevant sind
* Zeichensatz
  Die Zugeständnisse an EBCDIC (denn genau das waren sie letzten Endes)
  sind längst überholt. EBCID hat heute m.W. keine Bedeutung mehr.
  Auch IBM ist bei seinen Mainframes (bauen die überhaupt noch welche?)
  längst auf ASCII gewechselt.
* 2-er Komplement Arithmetik
  Ok, da mag es heute noch Ausnahmen geben, könnte sein. Ich denke
  allerdings nicht. Ich denke, es wäre kein Beinbruch, wenn man
  auch signed Arithmetik mit 2-er Kompl. Arithmetik im Hinterkopf
  aus seinem undefined Status holt. 1-er Komplement und sonstige
  Variationen sind längst tot, hat sich alles nicht wirklich
  bewährt.
* Floating Point
  Die ganze Welt verwendet mitlerweile die IEEE Funktionalität.
  OK, ältere Vaxen mit ihrem eigenen Floating Point Format haben
  dann das nachsehen. Würde mich allerdings wundern, wenn da noch
  groß Aufwand in die Neuentwicklung eines C-Compilers gesteckt wird.
* und eben die Sache mit der 0-Pointer-Konstanten
* was hab ich noch vergessen?

Denn die Sache ist doch die. Berücksichtigt man beim Programmieren all 
diese Dinge, dann hat man einen riesen Aufwand. Es würde mich sehr 
wundern, wenn man mehr als ein paar Prozentpunkte der real existierenden 
Programme nehmen könnte und auf eine Maschine mit einer derartigen 
Besonderheit laufen könnte, ohne dass es zu Problemen kommt. D.h. de 
facto hat sich die Computer-Industrie längst in all diesen Bereichen auf 
Standards eingeschossen. Die Zeit des ausprobierens ist längst vorbei. 
Die Flexibilität, die im C-Standard notwendig war um das alles unter 
einen Hut zu bringen, braucht man heutzutage gar nicht mehr. Aber ich 
weiß auch, dass die ISO-Gremien da sehr konservativ sind. Eher kann man 
die 10 Gebote ändern, als das etwas aus dem Standard rausfliegt, was da 
bereits drinn steht.

Karl Heinz Buchegger schrieb:
>   Auch IBM ist bei seinen Mainframes (bauen die überhaupt noch welche?)

Und ob die noch welche bauen: http://www-03.ibm.com/systems/z

Sind zwar rein physisch nicht grösser als deren Highend-RISCs und auch 
nicht schneller, aber in Sachen Verfügbarkeit ziemlich Spitze.

>   Die ganze Welt verwendet mitlerweile die IEEE Funktionalität.

Sogar besagte Mainframes beherrschen schon ein Weilchen neben IBMs altem 
Hex-Fliesskommaformat auch das IEEE-Format.

Karl Heinz Buchegger schrieb:
>> Heute nicht mehr. Gab es aber. Bei den Transputern war der Adressbereich
>> mit Vorzeichen realisiert, beim 16-Bitter T212 also -0x8000...+0x7FFF.
>> Die 0 folglich mitten drin.


Da gab's noch mehr: http://c-faq.com/null/machexamp.html . Überwiegend 
obsolet, trotzdem interessant zu wissen, finde ich.

A. K. schrieb:
> Sind zwar rein physisch nicht grösser als deren Highend-RISCs und auch
> nicht schneller, aber in Sachen Verfügbarkeit ziemlich Spitze.

Aufbau: http://www.redbooks.ibm.com/redpieces/abstracts/sg248049.html

Karl Heinz Buchegger schrieb:

> * was hab ich noch vergessen?

Funktionen ohne Prototyp, register, auto, Trigraphen, Duff's device, ...

1

send (to, from, count)

2

register short *to, *from;

3

register count;

4

{

5

        register n = (count + 7) / 8;

6

        switch(count % 8) {

7

        case 0: do {    *to = *from++;

8

        case 7:         *to = *from++;

9

        case 6:         *to = *from++;

10

        case 5:         *to = *from++;

11

        case 4:         *to = *from++;

12

        case 3:         *to = *from++;

13

        case 2:         *to = *from++;

14

        case 1:         *to = *from++;

15

                } while(--n > 0);

16

        }

17

}

Karl Heinz Buchegger schrieb:
> * Zeichensatz
>   Die Zugeständnisse an EBCDIC (denn genau das waren sie letzten Endes)
>   sind längst überholt. EBCID hat heute m.W. keine Bedeutung mehr.
>   Auch IBM ist bei seinen Mainframes (bauen die überhaupt noch welche?)
>   längst auf ASCII gewechselt.

Ich bekomme recht viele Daten in EBSCDIC, natürlich in irren Varianten
um deutsche Umlaute unterzubringen ... Das gibt's echt noch ;)

Ich war letztens mal an einem Vortrag über C. Der Dozent schloss mit der 
Bemerkung: C ist halt noch eine Sprache für Männer. :-)