🚀 go-pugleaf

"Nicolas Barbier" <nicolas.barbier@reply.in.group.invalid> schreef in
bericht news:pan.2004.07.20.08.59.32.928266@reply.in.group.invalid...
> On Mon, 19 Jul 2004 22:38:26 +0000, MaG wrote:
>
> > "Nicolas Barbier" <reply@in.group.invalid> schreef in bericht
> > news:40fba9ab$0$8988$6c56d894@feed0.news.be.easynet.net...
> >
> >> MaG wrote:
> >>
> >>> Null is niet altijd gelijk aan 0, hangt van de implementatie af.
> >>
> >> (NULL == 0) is implementatie-onafhankelijk steeds true. De mogelijke
> >> definities voor NULL zijn (void *) 0 en gewoon 0.
> >
> > "The language definition states that for each pointer type, there is a
> > special value--the ``null pointer''--which is distinguishable from all
> > other pointer values and which is ``guaranteed to compare unequal to a
> > pointer to any object or function.'' That is, the address-of operator &
> > will never yield a null pointer, nor will a successful call to malloc.
> > (malloc does return a null pointer when it fails, and this is a typical
> > use of null pointers: as a ``special'' pointer value with some other
> > meaning, usually ``not allocated'' or ``not pointing anywhere yet.'') As
> > mentioned above, there is a null pointer for each pointer type, and the
> > internal values of null pointers for different types may be different.
> > Although programmers need not know the internal values, the compiler
> > must always be informed which type of null pointer is required, so that
> > it can make the distinction if necessary."
> >
> > Dus NULL is niet noodzakelijk 0
>
> Wees duidelijk in wat je beweert: bedoel je "0", de interne representatie
> of "0", de letterlijke constante zoals je die in C typt? Als het over de
> constante gaat (meest waarschijnlijk), toon mij dan eens aan hoe jij die
> conclusie kan trekken uit de voorgaande tekst (het is wel waar, want het
> mag ook nog (void *) 0 zijn, maar dat kan ik niet afleiden uit de
> voorgaande tekst). Als het over de interne representatie gaat: die doet
> hier niet ter zake, aangezien de OP 0 als constante gebruikte.
>
> > en je wordt niet geacht de waarde van de NULL pointer te kennen.
>
> Je wordt niet verwacht de *interne representatie* van een null-pointer te
> kennen. Als je 0 schrijft in een pointer-context, betekent dat (voor een
> compiler, maar dat hoef je helemaal niet te weten) automatisch "de interne
> representatie van een null pointer van het type horende bij de context".
>
> Btw als je nog eens een stuk tekst citeert, geef dan een referentie naar
> de oorspronkelijke tekst. En lees hem misschien volledig:
>

*** Punt  1.1 in jouw link, maar dan wel via
http://www.eskimo.com/~scs/C-faq/top.html, (jouw link wordt obsolete)
*** De auteur stelt dan in 1.9 plots dat in bepaalde gevallen 0 wel als NULL
pointer gezien wordt en
*** als er geen prototype is of bij varargs weer niet. Zo moet steeds gaan
nadenken mag 0 nu wel of niet?
*** Waarom je het jezelf moeilijk maken als het simpel(er) kan met NULL?
*** En ja in C is het ook nog niet goed want daar is NULL dus 0. Misschien
dat ze daarom in ANSI C en C++ er (void *) 0 van
gemaakt hebben?
*** Ik ben nu eenmaal een voorstander van makkelijk(er) leesbare code.

> Quoting <url:http://www.lysator.liu.se/c/c-faq/c-1.html>:
>
> "1.9: But wouldn't it be better to use NULL (rather than 0) in case the
> value of NULL changes, perhaps on a machine with nonzero null pointers?
>
> No.  Although symbolic constants are often used in place of numbers
> because the numbers might change, this is not the reason that NULL is used
> in place of 0.  Once again, the language guarantees that source-code 0's
> (in pointer contexts) generate null pointers.  NULL is used only as a
> stylistic convention."
> ..of zowat elke andere vraag, aangezien het overal wordt herhaald dat je
> null-pointers ("0") niet mag verwarren met hun interne representatie (niet
> noodzakelijk het bitpatroon met enkel nullen).
>

*** Enne ik reageerde op de opmerking van OP dat hij dacht dat NULL pointers
altijd 0 waren. (hij zag 0x1e staan)
*** Voor de compiler ja dus, inwendig in de machine niet noodzakelijk.

--- 

MaG