🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: be.comp.programming
Article #2322

Re: [C++] fwrite + segmentation fault

#2322
From: Nicolas Barbier
Date: Tue, 20 Jul 2004 08:59
64 lines
4534 bytes
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/>
Technical Details
Message-ID: <pan.2004.07.20.08.59.32.928266@reply.in.group.invalid>
Path: arc1-ca.pugleaf.net!g2news1.google.com!news1.google.com!news.glorb.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!feed.news.tiscali.de!easynet-quince!easynet.net!feed0.news.be.easynet.net!not-for-mail
References: <6euaf0th4h3ctr13l2lk2se4lmbu39ueu6@4ax.com> <wfzJc.186138$XZ1.8812637@phobos.telenet-ops.be> <n3tdf018psossgbcc1ohrcgo8kbk3kastb@4ax.com> <tjEJc.1465$Ci.295274988@hestia.telenet-ops.be> <40fba9ab$0$8988$6c56d894@feed0.news.be.easynet.net> <C3YKc.664$dO1.199895245@hebe.telenet-ops.be>

Show Full Headers
Complete Article Headers
X-Google-Thread: fcea4,33ec3f0617e4db5
X-Google-Attributes: gidfcea4,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: arc1-ca.pugleaf.net!g2news1.google.com!news1.google.com!news.glorb.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!feed.news.tiscali.de!easynet-quince!easynet.net!feed0.news.be.easynet.net!not-for-mail
From: Nicolas Barbier <nicolas.barbier@reply.in.group.invalid>
Subject: Re: [C++] fwrite + segmentation fault
Date: Tue, 20 Jul 2004 10:59:33 +0200
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Message-ID: <pan.2004.07.20.08.59.32.928266@reply.in.group.invalid>
Newsgroups: be.comp.programming
References: <6euaf0th4h3ctr13l2lk2se4lmbu39ueu6@4ax.com> <wfzJc.186138$XZ1.8812637@phobos.telenet-ops.be> <n3tdf018psossgbcc1ohrcgo8kbk3kastb@4ax.com> <tjEJc.1465$Ci.295274988@hestia.telenet-ops.be> <40fba9ab$0$8988$6c56d894@feed0.news.be.easynet.net> <C3YKc.664$dO1.199895245@hebe.telenet-ops.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 65
Organization: [ posted via Easynet Belgium ]
NNTP-Posting-Date: 20 Jul 2004 09:00:13 GMT
NNTP-Posting-Host: 81.188.75.103
X-Trace: 1090314013 feed0.news.be.easynet.net 8984 [::ffff:81.188.75.103]:32829
X-Complaints-To: abuse@be.easynet.net