🚀 go-pugleaf

Lorenzo Dieryckx wrote:
> Hello,
> 
> Ik zit met een raar probleempje, en ik geraak er echt niet aan uit
> 
> ��n van mijn klassen heeft volgende memberfunctie:
> 
> int FileByteDestination::WriteBytes(const void * buffer, int count)
> {
>   if (_file == 0)
>     return 0;
> 
>   std::cout << "inside FileByteDestination::WriteBytes: _file = " << _file << std::endl;
>   std::cout << "number of chars to write = " << count << std::endl;
>   std::cout << "real number of chars in string: " << strlen((char *)buffer) << std::endl;
>   std::cout << "string to write :" << std::endl << (char *)buffer << std::endl;
>   int retval = fwrite(buffer, sizeof(char), count, _file);
> //sizeof(char) = 1 byte
>   std::cout << "wrote " << retval << " bytes" << std::endl << std::endl;
>   return retval;
> }
> 
> _file is een FILE* die ingevuld wordt in de constructor van FileByteDestination (mbv fopen())
> 
> als ze opgeroepen wordt met als parameters "ik ben lorenzo", 14
> produceert ze volgende output:
> 
> inside FileByteDestination::WriteBytes: _file = 0x1e
> number of chars to write = 14
> real number of chars in string: 14
> string to write:
> ik ben lorenzo
> Segmentation fault
> 
> als ik met gdb door mijn programma step,
> krijg ik de segv op de lijn "int retval = fwrite(buffer, sizeof(char), count, _file)"
> 
> Heeft iemand enig idee waardoor dit zou kunnen veroorzaakt zijn?
> 
> --
> Lorenzo Dieryckx
> mail: lorenzopuntdieryckxatpandorapuntbe


1) is _file wel goed geopend, heeft er per ongeluk niemand een close 
gedaan? Ben je zeker dat fopen geen errors gaf?
Als test plaats de open en de close eens in WriteBytes.

2) Wees er zeker van dat buffer goed is gedeclareerd, daarom:
    std::cout << "sizeof (buffer): " << sizeof (buffer) << std::endl;

--
  Kristoffel

On Thu, 15 Jul 2004 17:35:24 GMT, Kristoffel <kdg1955@yahoo.com> wrote:

>Lorenzo Dieryckx wrote:
>> Hello,
>> 
>> Ik zit met een raar probleempje, en ik geraak er echt niet aan uit
>> 
>> ��n van mijn klassen heeft volgende memberfunctie:
>> 
>> int FileByteDestination::WriteBytes(const void * buffer, int count)
>> {
>>   if (_file == 0)
>>     return 0;
>> 
>>   std::cout << "inside FileByteDestination::WriteBytes: _file = " << _file << std::endl;
>>   std::cout << "number of chars to write = " << count << std::endl;
>>   std::cout << "real number of chars in string: " << strlen((char *)buffer) << std::endl;
>>   std::cout << "string to write :" << std::endl << (char *)buffer << std::endl;
>>   int retval = fwrite(buffer, sizeof(char), count, _file);
>> //sizeof(char) = 1 byte
>>   std::cout << "wrote " << retval << " bytes" << std::endl << std::endl;
>>   return retval;
>> }
>> 
>> _file is een FILE* die ingevuld wordt in de constructor van FileByteDestination (mbv fopen())
>> 
>> als ze opgeroepen wordt met als parameters "ik ben lorenzo", 14
>> produceert ze volgende output:
>> 
>> inside FileByteDestination::WriteBytes: _file = 0x1e
>> number of chars to write = 14
>> real number of chars in string: 14
>> string to write:
>> ik ben lorenzo
>> Segmentation fault
>> 
>> als ik met gdb door mijn programma step,
>> krijg ik de segv op de lijn "int retval = fwrite(buffer, sizeof(char), count, _file)"
>> 
>> Heeft iemand enig idee waardoor dit zou kunnen veroorzaakt zijn?
>> 
>> --
>> Lorenzo Dieryckx
>> mail: lorenzopuntdieryckxatpandorapuntbe
>
>
>1) is _file wel goed geopend, heeft er per ongeluk niemand een close 
>gedaan? Ben je zeker dat fopen geen errors gaf?
>Als test plaats de open en de close eens in WriteBytes.
>
>2) Wees er zeker van dat buffer goed is gedeclareerd, daarom:
>    std::cout << "sizeof (buffer): " << sizeof (buffer) << std::endl;

Eerst en vooral hartelijk bedankt voor je hulp!
Het probleem is nu opgelost, maar toch is er nog
iets dat me dwars zit.

Zo zag mijn constructor er vroeger uit:
FileByteDestination::FileByteDestination(const String & uri, bool binary_mode) : 
  IByteDestination(uri)
{
  if (binary_mode)
    fopen(uri.c_str(), "wb");
  else
    fopen(uri.c_str(), "w");

  if (_file == 0)
    throw Exception("could not open file");
}

String is een wrapper rond de standaard char * strings,
een beetje achtergemaakt van de STLstring, maar dan met
een look en feel die ik liever heb.

anyway, _file was dus toch niet goed geopend. 
Ik heb nu bij de initialisatie nog eens   _file(0)
toegevoegd, en nu zie ik dus idd dat de file
niet goed geopend werd.
Ik dacht echter dat dit niet nodig was,
gezien ik in de manpages van fopen() gelezen
heb dat fopen() NULL returned als het openen
van de file mislukt. Gezien NULL volgens mij 
nog altijd 0 is (en niet 0x1e), dacht ik
dat _file sowieso op 0 zou staan als het openen 
van de file niet lukte.

Blijkbaar niet dus :-S

--
Lorenzo Dieryckx
mail: lorenzopuntdieryckxatpandorapuntbe
Laatste coole gehoorde uitspraak:
"Ik wil niet dat hij in die andere bureau
 zit. Voor ��n reden.... Hij zal be�nvloed
 worden... door... euhm... THE DARK SIDE!"
 - by sdr

On Thu, 15 Jul 2004 21:22:24 GMT, Lorenzo Dieryckx <dit.is.geen.email@adres.be> wrote:


>  if (binary_mode)
>    fopen(uri.c_str(), "wb");
>  else
>    fopen(uri.c_str(), "w");

Dit moet natuurlijk zijn:
if (binary_mode)
   _file = fopen(uri.c_str(), "wb");
else
   _file = fopen(uri.c_str(), "w");

How could I ever be so stupid.
Ik denk dat ik gedronken moet hebben op de avond dat ik FileByteDestination
programmeerde :-S
Sorry hoor...

--
Lorenzo Dieryckx
mail: lorenzopuntdieryckxatpandorapuntbe
Laatste coole gehoorde uitspraak:
"Ik wil niet dat hij in die andere bureau
 zit. Voor ��n reden.... Hij zal be�nvloed
 worden... door... euhm... THE DARK SIDE!"
 - by sdr

"Lorenzo Dieryckx" <dit.is.geen.email@adres.be> schreef in bericht
news:n3tdf018psossgbcc1ohrcgo8kbk3kastb@4ax.com...
> On Thu, 15 Jul 2004 17:35:24 GMT, Kristoffel <kdg1955@yahoo.com> wrote:
>
> >Lorenzo Dieryckx wrote:
> >> Hello,
> >>
> >> Ik zit met een raar probleempje, en ik geraak er echt niet aan uit
> >>
> >> ��n van mijn klassen heeft volgende memberfunctie:
> >>
> >> int FileByteDestination::WriteBytes(const void * buffer, int count)
> >> {
> >>   if (_file == 0)
> >>     return 0;
> >>
> >>   std::cout << "inside FileByteDestination::WriteBytes: _file = " <<
_file << std::endl;
> >>   std::cout << "number of chars to write = " << count << std::endl;
> >>   std::cout << "real number of chars in string: " << strlen((char
*)buffer) << std::endl;
> >>   std::cout << "string to write :" << std::endl << (char *)buffer <<
std::endl;
> >>   int retval = fwrite(buffer, sizeof(char), count, _file);
> >> //sizeof(char) = 1 byte
> >>   std::cout << "wrote " << retval << " bytes" << std::endl <<
std::endl;
> >>   return retval;
> >> }
> >>
> >> _file is een FILE* die ingevuld wordt in de constructor van
FileByteDestination (mbv fopen())
> >>
> >> als ze opgeroepen wordt met als parameters "ik ben lorenzo", 14
> >> produceert ze volgende output:
> >>
> >> inside FileByteDestination::WriteBytes: _file = 0x1e
> >> number of chars to write = 14
> >> real number of chars in string: 14
> >> string to write:
> >> ik ben lorenzo
> >> Segmentation fault
> >>
> >> als ik met gdb door mijn programma step,
> >> krijg ik de segv op de lijn "int retval = fwrite(buffer, sizeof(char),
count, _file)"
> >>
> >> Heeft iemand enig idee waardoor dit zou kunnen veroorzaakt zijn?
> >>
> >> --
> >> Lorenzo Dieryckx
> >> mail: lorenzopuntdieryckxatpandorapuntbe
> >
> >
> >1) is _file wel goed geopend, heeft er per ongeluk niemand een close
> >gedaan? Ben je zeker dat fopen geen errors gaf?
> >Als test plaats de open en de close eens in WriteBytes.
> >
> >2) Wees er zeker van dat buffer goed is gedeclareerd, daarom:
> >    std::cout << "sizeof (buffer): " << sizeof (buffer) << std::endl;
>
> Eerst en vooral hartelijk bedankt voor je hulp!
> Het probleem is nu opgelost, maar toch is er nog
> iets dat me dwars zit.
>
> Zo zag mijn constructor er vroeger uit:
> FileByteDestination::FileByteDestination(const String & uri, bool
binary_mode) :
>   IByteDestination(uri)
> {
>   if (binary_mode)
>     fopen(uri.c_str(), "wb");
>   else
>     fopen(uri.c_str(), "w");
>
>   if (_file == 0)
>     throw Exception("could not open file");
> }
>
> String is een wrapper rond de standaard char * strings,
> een beetje achtergemaakt van de STLstring, maar dan met
> een look en feel die ik liever heb.
>
> anyway, _file was dus toch niet goed geopend.
> Ik heb nu bij de initialisatie nog eens   _file(0)
> toegevoegd, en nu zie ik dus idd dat de file
> niet goed geopend werd.
> Ik dacht echter dat dit niet nodig was,
> gezien ik in de manpages van fopen() gelezen
> heb dat fopen() NULL returned als het openen
> van de file mislukt. Gezien NULL volgens mij
> nog altijd 0 is (en niet 0x1e), dacht ik
> dat _file sowieso op 0 zou staan als het openen
> van de file niet lukte.
>
> Blijkbaar niet dus :-S


Null is niet altijd gelijk aan 0, hangt van de implementatie af. Moet
eigenlijk (_file == (FILE *)0) zijn.

Of (_file == NULL), da's gemakkelijker.  :-)) t Is niet voor niets dat NULL
gedefinieerd wordt.

MaG

"Lorenzo Dieryckx" <dit.is.geen.email@adres.be> schreef in bericht
news:n3tdf018psossgbcc1ohrcgo8kbk3kastb@4ax.com...
> On Thu, 15 Jul 2004 17:35:24 GMT, Kristoffel <kdg1955@yahoo.com> wrote:
>
> >Lorenzo Dieryckx wrote:
> >> Hello,
> >>
> >> Ik zit met een raar probleempje, en ik geraak er echt niet aan uit
> >>
> >> ��n van mijn klassen heeft volgende memberfunctie:
> >>
> >> int FileByteDestination::WriteBytes(const void * buffer, int count)
> >> {
> >>   if (_file == 0)
> >>     return 0;
> >>
> >>   std::cout << "inside FileByteDestination::WriteBytes: _file = " <<
_file << std::endl;
> >>   std::cout << "number of chars to write = " << count << std::endl;
> >>   std::cout << "real number of chars in string: " << strlen((char
*)buffer) << std::endl;
> >>   std::cout << "string to write :" << std::endl << (char *)buffer <<
std::endl;
> >>   int retval = fwrite(buffer, sizeof(char), count, _file);
> >> //sizeof(char) = 1 byte
> >>   std::cout << "wrote " << retval << " bytes" << std::endl <<
std::endl;
> >>   return retval;
> >> }
> >>
> >> _file is een FILE* die ingevuld wordt in de constructor van
FileByteDestination (mbv fopen())
> >>
> >> als ze opgeroepen wordt met als parameters "ik ben lorenzo", 14
> >> produceert ze volgende output:
> >>
> >> inside FileByteDestination::WriteBytes: _file = 0x1e
> >> number of chars to write = 14
> >> real number of chars in string: 14
> >> string to write:
> >> ik ben lorenzo
> >> Segmentation fault
> >>
> >> als ik met gdb door mijn programma step,
> >> krijg ik de segv op de lijn "int retval = fwrite(buffer, sizeof(char),
count, _file)"
> >>
> >> Heeft iemand enig idee waardoor dit zou kunnen veroorzaakt zijn?
> >>
> >> --
> >> Lorenzo Dieryckx
> >> mail: lorenzopuntdieryckxatpandorapuntbe
> >
> >
> >1) is _file wel goed geopend, heeft er per ongeluk niemand een close
> >gedaan? Ben je zeker dat fopen geen errors gaf?
> >Als test plaats de open en de close eens in WriteBytes.
> >
> >2) Wees er zeker van dat buffer goed is gedeclareerd, daarom:
> >    std::cout << "sizeof (buffer): " << sizeof (buffer) << std::endl;
>
> Eerst en vooral hartelijk bedankt voor je hulp!
> Het probleem is nu opgelost, maar toch is er nog
> iets dat me dwars zit.
>
> Zo zag mijn constructor er vroeger uit:
> FileByteDestination::FileByteDestination(const String & uri, bool
binary_mode) :
>   IByteDestination(uri)
> {
>   if (binary_mode)
>     fopen(uri.c_str(), "wb");
>   else
>     fopen(uri.c_str(), "w");
>
>   if (_file == 0)
>     throw Exception("could not open file");
> }
>
> String is een wrapper rond de standaard char * strings,
> een beetje achtergemaakt van de STLstring, maar dan met
> een look en feel die ik liever heb.
>
> anyway, _file was dus toch niet goed geopend.
> Ik heb nu bij de initialisatie nog eens   _file(0)
> toegevoegd, en nu zie ik dus idd dat de file
> niet goed geopend werd.
> Ik dacht echter dat dit niet nodig was,
> gezien ik in de manpages van fopen() gelezen
> heb dat fopen() NULL returned als het openen
> van de file mislukt. Gezien NULL volgens mij
> nog altijd 0 is (en niet 0x1e), dacht ik
> dat _file sowieso op 0 zou staan als het openen
> van de file niet lukte.
>
> Blijkbaar niet dus :-S


Null is niet altijd gelijk aan 0, hangt van de implementatie af. Moet
eigenlijk (_file == (FILE *)0) zijn.

Of (_file == NULL), da's gemakkelijker.  :-)) t Is niet voor niets dat NULL
gedefinieerd wordt.

MaG

"Lorenzo Dieryckx" <dit.is.geen.email@adres.be> schreef in bericht
news:n3tdf018psossgbcc1ohrcgo8kbk3kastb@4ax.com...
> On Thu, 15 Jul 2004 17:35:24 GMT, Kristoffel <kdg1955@yahoo.com> wrote:
>
> >Lorenzo Dieryckx wrote:
> >> Hello,
> >>
> >> Ik zit met een raar probleempje, en ik geraak er echt niet aan uit
> >>
> >> ��n van mijn klassen heeft volgende memberfunctie:
> >>
> >> int FileByteDestination::WriteBytes(const void * buffer, int count)
> >> {
> >>   if (_file == 0)
> >>     return 0;
> >>
> >>   std::cout << "inside FileByteDestination::WriteBytes: _file = " <<
_file << std::endl;
> >>   std::cout << "number of chars to write = " << count << std::endl;
> >>   std::cout << "real number of chars in string: " << strlen((char
*)buffer) << std::endl;
> >>   std::cout << "string to write :" << std::endl << (char *)buffer <<
std::endl;
> >>   int retval = fwrite(buffer, sizeof(char), count, _file);
> >> //sizeof(char) = 1 byte
> >>   std::cout << "wrote " << retval << " bytes" << std::endl <<
std::endl;
> >>   return retval;
> >> }
> >>
> >> _file is een FILE* die ingevuld wordt in de constructor van
FileByteDestination (mbv fopen())
> >>
> >> als ze opgeroepen wordt met als parameters "ik ben lorenzo", 14
> >> produceert ze volgende output:
> >>
> >> inside FileByteDestination::WriteBytes: _file = 0x1e
> >> number of chars to write = 14
> >> real number of chars in string: 14
> >> string to write:
> >> ik ben lorenzo
> >> Segmentation fault
> >>
> >> als ik met gdb door mijn programma step,
> >> krijg ik de segv op de lijn "int retval = fwrite(buffer, sizeof(char),
count, _file)"
> >>
> >> Heeft iemand enig idee waardoor dit zou kunnen veroorzaakt zijn?
> >>
> >> --
> >> Lorenzo Dieryckx
> >> mail: lorenzopuntdieryckxatpandorapuntbe
> >
> >
> >1) is _file wel goed geopend, heeft er per ongeluk niemand een close
> >gedaan? Ben je zeker dat fopen geen errors gaf?
> >Als test plaats de open en de close eens in WriteBytes.
> >
> >2) Wees er zeker van dat buffer goed is gedeclareerd, daarom:
> >    std::cout << "sizeof (buffer): " << sizeof (buffer) << std::endl;
>
> Eerst en vooral hartelijk bedankt voor je hulp!
> Het probleem is nu opgelost, maar toch is er nog
> iets dat me dwars zit.
>
> Zo zag mijn constructor er vroeger uit:
> FileByteDestination::FileByteDestination(const String & uri, bool
binary_mode) :
>   IByteDestination(uri)
> {
>   if (binary_mode)
>     fopen(uri.c_str(), "wb");
>   else
>     fopen(uri.c_str(), "w");
>
>   if (_file == 0)
>     throw Exception("could not open file");
> }
>
> String is een wrapper rond de standaard char * strings,
> een beetje achtergemaakt van de STLstring, maar dan met
> een look en feel die ik liever heb.
>
> anyway, _file was dus toch niet goed geopend.
> Ik heb nu bij de initialisatie nog eens   _file(0)
> toegevoegd, en nu zie ik dus idd dat de file
> niet goed geopend werd.
> Ik dacht echter dat dit niet nodig was,
> gezien ik in de manpages van fopen() gelezen
> heb dat fopen() NULL returned als het openen
> van de file mislukt. Gezien NULL volgens mij
> nog altijd 0 is (en niet 0x1e), dacht ik
> dat _file sowieso op 0 zou staan als het openen
> van de file niet lukte.
>
> Blijkbaar niet dus :-S


Null is niet altijd gelijk aan 0, hangt van de implementatie af. Moet
eigenlijk (_file == (FILE *)0) zijn.

Of (_file == NULL), da's gemakkelijker.  :-)) t Is niet voor niets dat NULL
gedefinieerd wordt.

MaG

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.

> Moet eigenlijk (_file == (FILE *)0) zijn.

In deze context wordt 0 geinterpreteerd als pointer, en is de (FILE *)
nergens voor nodig (behalve eventueel duidelijkheid). De enige
probleemgevallen zijn die waarin een pointer en een integer beiden mogelijk
zijn, bijvoorbeeld als argument bij een printf functieoproep.

-- 
Nicolas Barbier
Protecting innovation against patent inflation <url:http://swpat.ffii.org/>

"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 en je wordt niet geacht de waarde van de
NULL pointer te kennen.

Gebruik altijd NULL zou ik zo zeggen. ;-)

--- 

MaG

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:

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).

-- 
Nicolas Barbier
Protecting innovation against patent inflation <url:http://swpat.ffii.org/>

"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