Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #70695 > unrolled thread

What is the data structure of a NULL?

Back to article view | Back to comp.lang.c++

Contents

  What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-27 13:24 -0800
    Re: What is the data structure of a NULL? Ian Collins <ian-news@hotmail.com> - 2019-12-28 10:36 +1300
      Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-27 13:55 -0800
        Re: What is the data structure of a NULL? Bo Persson <bo@bo-persson.se> - 2019-12-28 11:28 +0100
      Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-27 20:50 -0500
        Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-28 17:14 -0800
        Re: What is the data structure of a NULL? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 20:56 -0800
    Re: What is the data structure of a NULL? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-27 22:42 +0100
      Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-27 13:55 -0800
        Re: What is the data structure of a NULL? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-27 23:10 +0100
        Re: What is the data structure of a NULL? Öö Tiib <ootiib@hot.ee> - 2019-12-27 14:15 -0800
          Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-27 14:24 -0800
            Re: What is the data structure of a NULL? Öö Tiib <ootiib@hot.ee> - 2019-12-27 14:41 -0800
            Re: What is the data structure of a NULL? Manfred <noname@add.invalid> - 2019-12-28 20:11 +0100
              Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-28 17:16 -0800
                Re: What is the data structure of a NULL? Manfred <noname@invalid.add> - 2019-12-29 17:52 +0100
                  Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-29 12:21 -0800
        Re: What is the data structure of a NULL? Bart <bc@freeuk.com> - 2019-12-28 01:46 +0000
          Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-28 17:17 -0800
            Re: What is the data structure of a NULL? Bart <bc@freeuk.com> - 2019-12-29 01:42 +0000
              Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-28 18:39 -0800
    Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-28 02:14 -0800
      Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-28 08:33 -0600
        Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-28 13:22 -0800
          Re: What is the data structure of a NULL? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-28 16:02 -0800
            Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-28 22:37 -0600
          Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-28 22:37 -0600
            Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-28 21:12 -0800
              Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-29 04:45 -0600
                Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 13:31 -0800
                  Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-29 21:34 -0600
                    Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 22:48 -0800
                Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-29 20:20 -0500
                  Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-29 21:50 -0600
                    Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 22:46 -0800
                      Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-30 10:25 +0100
                        Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 05:20 -0600
                          Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-30 17:24 +0100
                            Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 17:22 -0600
                              Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-31 13:57 +0100
                                Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-31 07:33 -0600
                                  Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-31 15:45 +0100
                          Re: What is the data structure of a NULL? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-30 18:16 +0000
                            Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-30 10:45 -0800
                              Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 17:29 -0600
                                Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-30 21:48 -0800
                      Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 04:19 -0600
                        Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-30 17:27 +0100
                      Re: What is the data structure of a NULL? Öö Tiib <ootiib@hot.ee> - 2019-12-30 03:25 -0800
                        Re: What is the data structure of a NULL? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-31 21:54 +0000
                    Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-30 06:03 -0800
                      Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 17:01 -0600
                        Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-30 21:42 -0500
                          Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-31 06:03 -0600
                            Re: What is the data structure of a NULL? Öö Tiib <ootiib@hot.ee> - 2019-12-31 06:17 -0800
                              Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-31 10:46 -0600
                                Re: What is the data structure of a NULL? Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 16:57 +0000
                                  Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-31 18:15 +0100
                                    Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-31 11:20 -0800
                                      Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2020-01-01 17:01 +0100
                                  Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-31 11:21 -0600
                                    Re: What is the data structure of a NULL? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-31 21:37 +0000
                                    Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-31 15:21 -0800
                                Re: What is the data structure of a NULL? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 17:26 +0000
                                Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-31 23:30 -0500
                                  Re: What is the data structure of a NULL? Manfred <noname@add.invalid> - 2020-01-01 18:10 +0100
                                    Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-01 12:21 -0500
                            Re: What is the data structure of a NULL? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 15:20 +0000
                              Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-31 11:11 -0800
                                Re: What is the data structure of a NULL? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 19:47 +0000
                            Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-31 10:27 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#70866

David Brown wrote:
> Ned Latham wrote:
> > David Brown wrote:

----snip----

> > > I only looked at the source code you linked - it is not complete,
> > 
> > Bullshit.
> > 
> > > because it is written in a sort-of C, sort-of C++, sort-of something
> > > else mix using your own macros.
> > 
> > That's noi reason for saying "incomplete".,
>
> That is not why I said it was incomplete.  I said it was incomplete
> because you linked to some source code that relied on non-standard
> headers that were not included in your links.

That's another lie. And a really stupid one. Here's your statement as
it was before I split it for reply:

"I only looked at the source code you linked - it is not complete,
because it is written in a sort-of C, sort-of C++, sort-of something
else mix using your own macros."

You're a dimwit trying to cover your stupidity with lies. You'll
have much geater success if the only person you try to fool is
you.

----snip----

[toc] | [prev] | [next] | [standalone]

#70869

On 31/12/2019 14:33, Ned Latham wrote:
> David Brown wrote:
>> Ned Latham wrote:
>>> David Brown wrote:
> 
> ----snip----
> 
>>>> I only looked at the source code you linked - it is not complete,
>>>
>>> Bullshit.
>>>
>>>> because it is written in a sort-of C, sort-of C++, sort-of something
>>>> else mix using your own macros.
>>>
>>> That's noi reason for saying "incomplete".,
>>
>> That is not why I said it was incomplete.  I said it was incomplete
>> because you linked to some source code that relied on non-standard
>> headers that were not included in your links.
> 
> That's another lie. And a really stupid one. Here's your statement as
> it was before I split it for reply:
> 
> "I only looked at the source code you linked - it is not complete,
> because it is written in a sort-of C, sort-of C++, sort-of something
> else mix using your own macros."
> 
> You're a dimwit trying to cover your stupidity with lies. You'll
> have much geater success if the only person you try to fool is
> you.
> 

Ah, the old "take stuff out of context and then sprinkle in wild
insults" ploy.  Yes, I can clearly see how that changes your incomplete
code into complete code.

Your code was written using pointless fake-BASIC macros.  Those were not
defined anywhere in the code you linked.  Therefore your code was
incomplete.

(There might be all sorts of other things missing - or it might be
otherwise complete.  I haven't checked.)

[toc] | [prev] | [next] | [standalone]

#70833

Ned Latham <nedlatham@woden.valhalla.oz> writes:

> David Brown wrote:
<cut>
>> [...] New and delete rather than malloc and free?

I suspect this is the heart of the problem.

> Those are design decisions too, idiot. The C++ library throws exceptions.
> Exceptions are evil, especially in low-level code.
>
> And BTW, it's calloc()

You assume that null pointers are represented with all-bits-zero because
you want to use calloc, and you want to use calloc because you think new
will throw an exception.  (If you know about non-throwing new then I
can't see any reason for not using it, thereby allowing null pointers to
dealt with by a constructor as C++ intended.)

Also your test for null pointers being all-bits-zero (as provided by
calloc) is flawed:

#ifndef NULL
#define NULL 0
#elif (NULL != 0)
#error NULL is defined as non-zero!
#endif

NULL will always compare == 0, even when null pointers do not have all
bits zero.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#70835

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Ned Latham <nedlatham@woden.valhalla.oz> writes:
[...]
>> Those are design decisions too, idiot. The C++ library throws exceptions.
>> Exceptions are evil, especially in low-level code.
>>
>> And BTW, it's calloc()
>
> You assume that null pointers are represented with all-bits-zero because
> you want to use calloc, and you want to use calloc because you think new
> will throw an exception.  (If you know about non-throwing new then I
> can't see any reason for not using it, thereby allowing null pointers to
> dealt with by a constructor as C++ intended.)

Is that the whole point of showing us that code, that it depends
on a null pointer being represented as all-bits-zero because it
uses calloc()?  I wonder why Ned didn't just say so rather than
sending us on a wild goose chase digging through some online code.

I'll probably never know, because I won't waste my time talking to
someone who calls people idiots.

I can imagine that kind of thing not being entirely a bad idea in
code that's not intended to be portable.  Using memset or calloc
while assuming that null pointers (and floating-point zeros,
if applicable) are represented as all-bits-zero is strictly not
portable, but it's likely good enough for target-specific code.
I'd still try to avoid that assumption unless I had a pretty good
reason to depend on it, and I'd be more likely to do something
like that in C than in C++.  If I wanted to initialize a structure
to zeros, I'd rather use a { 0 } initializer than anything that
depends on representation.

I suspect Ned will take this as proof that I agree with him.
For the record, I don't.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#70841

Keith Thompson wrote:

----snip----

> Is that the whole point of showing us that code, that it depends
> on a null pointer being represented as all-bits-zero because it
> uses calloc()?

No. Try reading with your eyes open.

Idiot.

>                 I wonder why Ned didn't just say so rather than
> sending us on a wild goose chase digging through some online code.
>
> I'll probably never know, because I won't waste my time talking to
> someone who calls people idiots.

Do you waste time talking to people who misrepresent what they've been
given and then sneer at it?

----snip----

[toc] | [prev] | [next] | [standalone]

#70852

Ned Latham <nedlatham@woden.valhalla.oz> writes:
> Keith Thompson wrote:
> ----snip----
>
>> Is that the whole point of showing us that code, that it depends
>> on a null pointer being represented as all-bits-zero because it
>> uses calloc()?
>
> No. Try reading with your eyes open.
>
> Idiot.

It's not worth my time to read your code to try (and quite possibly
fail) to figure out what you're talking about.  And it's no longer
worth my time to interact with you at all.

*Plonk*

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#70807

Keith Thompson wrote:
> Ned Latham writes:
> > James Kuyper wrote:
> > > Ned Latham wrote:
> > > > Keith Thompson wrote:
> > > > >
> > > > > You indicated that it's useful to know how a null pointer is
> > > > > represented.  How is it useful?  Most of the time, the representation
> > > > > doesn't matter.
> > > >
> > > > Knowing it's useful in that it enables me to use it.
> > >
> > > Can you give an example of code involving a null pointer that you could
> > > not have used if you had not known how null pointers are represented? I
> > > write code that deals correctly with null pointers all the time, and to
> > > the best of my knowledge, not a single line of code I've ever written
> > > would need a re-write if ported to a system which uses a different
> > > representation for null pointers.
> >
> > http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
> >
> > Check AVLC and ListC, also read
> > http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html
>
> Can you give a *succinct* example?  I'm not going to spend the time it
> would take to read that.

What you've got is working code and documentation describing it. The AVLC
Specification document details three funcions that take void* parameters
and also return void*, Extract(), Find(), Insert().

----snip----

[toc] | [prev] | [next] | [standalone]

#70828

On 30/12/2019 11:19, Ned Latham wrote:
> Keith Thompson wrote:
>> Ned Latham writes:
>>> James Kuyper wrote:
>>>> Ned Latham wrote:
>>>>> Keith Thompson wrote:
>>>>>>
>>>>>> You indicated that it's useful to know how a null pointer is
>>>>>> represented.  How is it useful?  Most of the time, the representation
>>>>>> doesn't matter.
>>>>>
>>>>> Knowing it's useful in that it enables me to use it.
>>>>
>>>> Can you give an example of code involving a null pointer that you could
>>>> not have used if you had not known how null pointers are represented? I
>>>> write code that deals correctly with null pointers all the time, and to
>>>> the best of my knowledge, not a single line of code I've ever written
>>>> would need a re-write if ported to a system which uses a different
>>>> representation for null pointers.
>>>
>>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
>>>
>>> Check AVLC and ListC, also read
>>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html
>>
>> Can you give a *succinct* example?  I'm not going to spend the time it
>> would take to read that.
> 
> What you've got is working code and documentation describing it. The AVLC
> Specification document details three funcions that take void* parameters
> and also return void*, Extract(), Find(), Insert().
> 

Even though you apparently have no intention of answering Keith's
questions sensibly, could you at least say why you think a function
returning void* is dependent on the representation of null pointers?

Your documentation says your code relies on void* being the same size as
int.  I didn't see anything in the code that actually depends on that
(but I have not gone through it in detail) - but that bears no direct
relationship on the representation of null pointer constants.

[toc] | [prev] | [next] | [standalone]

#70809

On Monday, 30 December 2019 08:47:01 UTC+2, Keith Thompson  wrote:
> Ned Latham <nedlatham@woden.valhalla.oz> writes:
> >
> > http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
> >
> > Check AVLC and ListC, also read
> > http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html

It is not simple to find apprentices for a master with such style.   

> Can you give a *succinct* example?  I'm not going to spend the time it
> would take to read that.

I have seen lot of code that assumes that null pointer has all bits clear.
Most typical case is that contents of some byte buffer is zeroed. Can be
calloc, memset, resize of byte vector or default-initialized byte array. As
next step it is assumed that (properly aligned) bytes in such buffer can
be now treated as nullptr. 

> Of course you *can* write code that depends on the representation of a
> null pointer, but there is rarely a good reason to do so.

The usual reason is ignorance. Rare people know details of ABI of C++
for one or other platform and next to no one has expertise in extent
of allowable by standard freedoms in ABI. Literal 0 is required to be
null pointer constant and incorrect assumption that null pointer constant
is required to have all bits clear is therefore trivial to make.

It is often not expensive to rewrite such places into conforming and it
likely does not affect any performance but fixes of never-manifesting
defects can be intricate to sell and last minute changes can cause
actual defects (in non-trivial code on about 50% of cases IME).  So
in review I typically request unit tests and static asserts about
platform-specific assumptions instead of rewrite.

[toc] | [prev] | [next] | [standalone]

#70909

On Mon, 2019-12-30, Öö Tiib wrote:
> On Monday, 30 December 2019 08:47:01 UTC+2, Keith Thompson  wrote:
>> Ned Latham <nedlatham@woden.valhalla.oz> writes:
>> >
>> > http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
>> >
>> > Check AVLC and ListC, also read
>> > http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html
>
> It is not simple to find apprentices for a master with such style.   
>
>> Can you give a *succinct* example?  I'm not going to spend the time it
>> would take to read that.
>
> I have seen lot of code that assumes that null pointer has all bits clear.
> Most typical case is that contents of some byte buffer is zeroed. Can be
> calloc, memset, resize of byte vector or default-initialized byte array. As
> next step it is assumed that (properly aligned) bytes in such buffer can
> be now treated as nullptr. 
>
>> Of course you *can* write code that depends on the representation of a
>> null pointer, but there is rarely a good reason to do so.
>
> The usual reason is ignorance. Rare people know details of ABI of C++
> for one or other platform and next to no one has expertise in extent
> of allowable by standard freedoms in ABI. Literal 0 is required to be
> null pointer constant and incorrect assumption that null pointer constant
> is required to have all bits clear is therefore trivial to make.
>
> It is often not expensive to rewrite such places into conforming and it
> likely does not affect any performance but fixes of never-manifesting
> defects can be intricate to sell and last minute changes can cause
> actual defects (in non-trivial code on about 50% of cases IME).  So
> in review I typically request unit tests and static asserts about
> platform-specific assumptions instead of rewrite.

Thanks -- a sane and useful posting in this thread, at last.
(Other postings have been sane, but not useful.  Including mine.)

I'm going to stop reading now, so my last Usenet read of 2019 is a
good one.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#70821

Ned Latham wrote:
> James Kuyper wrote:
...
> > Can you give an example of code involving a null pointer that you could
> > not have used if you had not known how null pointers are represented? I
> > write code that deals correctly with null pointers all the time, and to
> > the best of my knowledge, not a single line of code I've ever written
> > would need a re-write if ported to a system which uses a different
> > representation for null pointers.

> http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html

> Check AVLC and ListC, also read
> http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html

That is not the kind of response I was asking for. Let me be more explicit:
I'm looking for a single C++ construct, from a single line of code, that
you were only able to use because of what you know about how null pointers
are represented on the target implementation. That is, inherently, a
construct that would not produce the desired result if the code were ported
to an implementation that uses a different way to represent null pointers.
It's fine if you need to provide additional lines of code, or even system
documentation, to provide the proper context for that construct. However,
I need you to actually identify the particular construct you're referring
to. Can you give me the exact location in that body of code of at least
one such construct? Better yet, could you quote that line of code?

[toc] | [prev] | [next] | [standalone]

#70839

James Kuyper wrote:
> Ned Latham wrote:
>> James Kuyper wrote:
> ...
>> > Can you give an example of code involving a null pointer that you could
>> > not have used if you had not known how null pointers are represented? I
>> > write code that deals correctly with null pointers all the time, and to
>> > the best of my knowledge, not a single line of code I've ever written
>> > would need a re-write if ported to a system which uses a different
>> > representation for null pointers.
>
>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
>
>> Check AVLC and ListC, also read
>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html
>
> That is not the kind of response I was asking for. Let me be more explicit:
> I'm looking for a single C++ construct, from a single line of code, that
> you were only able to use because of what you know about how null pointers
> are represented on the target implementation. That is, inherently, a
> construct that would not produce the desired result if the code were ported
> to an implementation that uses a different way to represent null pointers.
> It's fine if you need to provide additional lines of code, or even system
> documentation, to provide the proper context for that construct. However,
> I need you to actually identify the particular construct you're referring
> to. Can you give me the exact location in that body of code of at least
> one such construct? Better yet, could you quote that line of code?

No. get off your arese and look.

[toc] | [prev] | [next] | [standalone]

#70845

On 12/30/19 6:01 PM, Ned Latham wrote:
> James Kuyper wrote:
>> Ned Latham wrote:
...
>>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
>>
>>> Check AVLC and ListC, also read
>>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html
>>
>> That is not the kind of response I was asking for. Let me be more explicit:
>> I'm looking for a single C++ construct, from a single line of code, that
>> you were only able to use because of what you know about how null pointers
>> are represented on the target implementation. That is, inherently, a
>> construct that would not produce the desired result if the code were ported
>> to an implementation that uses a different way to represent null pointers.
>> It's fine if you need to provide additional lines of code, or even system
>> documentation, to provide the proper context for that construct. However,
>> I need you to actually identify the particular construct you're referring
>> to. Can you give me the exact location in that body of code of at least
>> one such construct? Better yet, could you quote that line of code?
> 
> No. get off your arese and look.

Why? It shouldn't take you more than a few seconds to honor my request,
while it might take me hours to honor yours.
The fundamental problem is that I won't even necessarily recognize what
you're referring to, even if it's staring me in the face. There's a
pretty good chance that what you think is code that depends upon the
representation of null pointers is, in fact, not so dependent.
Alternatively, it might be code that I incorrectly think has no such
dependence - either way, I won't recognize it when I see it. However, if
you would just identify the particular code you're talking about, which
should only take you a few seconds, it might save me hours of possibly
fruitless searching, and we can move on to the discussion of whether or
not you're correct, and whether or not it was actually necessary to
write such code.

[toc] | [prev] | [next] | [standalone]

#70858

James Kuyper wrote:

----snip----

> The fundamental problem is that I won't even necessarily recognize what
> you're referring to, even if it's staring me in the face. There's a
> pretty good chance that what you think is code that depends upon the
> representation of null pointers is, in fact, not so dependent.

I don't know why you haven't already got it. If NULL == 0 the same
logic can be used with pointers as with integers and all their bitwidth
lookalikes and all the functions that require or return those types.
Tests like

if (!(array=calloc(hemeny,sizeof(arrayrcrd)))) // then deal with OOM.

wouldn't work correctly otherwise.

Knowing the way NULL is represented can be useful.

----snip----

[toc] | [prev] | [next] | [standalone]

#70867

On Tuesday, 31 December 2019 14:03:46 UTC+2, Ned Latham  wrote:
> James Kuyper wrote:
> 
> ----snip----
> 
> > The fundamental problem is that I won't even necessarily recognize what
> > you're referring to, even if it's staring me in the face. There's a
> > pretty good chance that what you think is code that depends upon the
> > representation of null pointers is, in fact, not so dependent.
> 
> I don't know why you haven't already got it. If NULL == 0 the same
> logic can be used with pointers as with integers and all their bitwidth
> lookalikes and all the functions that require or return those types.

[conv.ptr] "A null pointer constant is an integer literal with value
zero or a prvalue of type std::nullptr_t."

It does nowhere say that null pointer constant has no bits set only
that integer literal 0 is useful as it.

> Tests like
> 
> if (!(array=calloc(hemeny,sizeof(arrayrcrd)))) // then deal with OOM.
> 
> wouldn't work correctly otherwise.

That is addressed by different place of standard:
[conv.bool]
"A zero value, null pointer value, or null member pointer value is
converted to false; any other value is converted to true."

It does not say that bit-wise checks are made, if it contains null
pointer then it is converted to false regardless if null pointer
has all bits clear, or some, or none.

> Knowing the way NULL is represented can be useful.

You were asked example of it ... is it so hard to produce one?

[toc] | [prev] | [next] | [standalone]

#70878

Öö Tiib wrote:
> Ned Latham  wrote:

----snip----

> > Tests like
> >
> > if (!(array=calloc(hemeny,sizeof(arrayrcrd)))) // then deal with OOM.
> >
> > wouldn't work correctly otherwise.
>
> That is addressed by different place of standard:
> [conv.bool]
> "A zero value, null pointer value, or null member pointer value is
> converted to false; any other value is converted to true."

News to me. Might be because I'm a lazy reader or because my references
are out of date: Kernigan and Ritchie for C (ANSI 2) and Stroustrup
(Edition 3) for C++. Both 1990s.

> It does not say that bit-wise checks are made,

If NULL == 0, bitwise checks aren't required, just a check of the
Z flag of the register that received the return.

>                                                if it contains null
> pointer then it is converted to false regardless if null pointer
> has all bits clear, or some, or none.

It's a good, portable way of applying logic to pointer values.

> > Knowing the way NULL is represented can be useful.
>
> You were asked example of it ... is it so hard to produce one?

int, i, j;

if (i - j == NULL) // then do whatever.

[toc] | [prev] | [next] | [standalone]

#70880

On 2019-12-31, Ned Latham <nedlatham@woden.valhalla.oz> wrote:
>
>> It does not say that bit-wise checks are made,
>
> If NULL == 0, bitwise checks aren't required, just a check of the
> Z flag of the register that received the return.

0 is converted to NULL pointer.

>
>>                                                if it contains null
>> pointer then it is converted to false regardless if null pointer
>> has all bits clear, or some, or none.
>
> It's a good, portable way of applying logic to pointer values.
>
>> > Knowing the way NULL is represented can be useful.
>>
>> You were asked example of it ... is it so hard to produce one?
>
> int, i, j;
>
> if (i - j == NULL) // then do whatever.

except that this does not compiles. Imlicit conversion of int to pointer
is not done...



-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#70887

On 31/12/2019 17:57, Melzzzzz wrote:
> On 2019-12-31, Ned Latham <nedlatham@woden.valhalla.oz> wrote:
>>
>>> It does not say that bit-wise checks are made,
>>
>> If NULL == 0, bitwise checks aren't required, just a check of the
>> Z flag of the register that received the return.
> 
> 0 is converted to NULL pointer.
> 
>>
>>>                                                 if it contains null
>>> pointer then it is converted to false regardless if null pointer
>>> has all bits clear, or some, or none.
>>
>> It's a good, portable way of applying logic to pointer values.
>>
>>>> Knowing the way NULL is represented can be useful.
>>>
>>> You were asked example of it ... is it so hard to produce one?
>>
>> int, i, j;
>>
>> if (i - j == NULL) // then do whatever.
> 
> except that this does not compiles. Imlicit conversion of int to pointer
> is not done...
> 

It might compile - "NULL" can be defined as "#define NULL 0" rather 
than, say, "((void*) 0)".

It is not in any way dependent on the representation of null pointers, 
as you probably know.

[toc] | [prev] | [next] | [standalone]

#70904

David Brown <david.brown@hesbynett.no> writes:
[...]
> It might compile - "NULL" can be defined as "#define NULL 0" rather
> than, say, "((void*) 0)".
>
> It is not in any way dependent on the representation of null pointers,
> as you probably know.

In C, NULL can be defined as 0 or as ((void*)0).  In C++, ((void*)0) is
not a valid definition of NULL, because C++'s definition of "null
pointer constant" is more strict than C's.

    A *null pointer constant* is an integer literal with value zero
    or a prvalue of type std::nullptr_t. A null pointer constant
    can be converted to a pointer type; the result is the *null
    pointer value* of that type and is distinguishable from every
    other value of object pointer or function pointer type.

(In C++11 and earlier, a integral constant expression with value
0 could be a null pointer constant, but C++14 restricted this to
integer literals.  ((void*)0) hasn't been a valid C++ null pointer
constant going back at least to C++98.)

But yes, NULL might be usable in a context that requires an integer
value depending on how the implementation defines it.  Of course it
would be silly to depend on that.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#70932

On 31/12/2019 20:20, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> It might compile - "NULL" can be defined as "#define NULL 0" rather
>> than, say, "((void*) 0)".
>>
>> It is not in any way dependent on the representation of null pointers,
>> as you probably know.
> 
> In C, NULL can be defined as 0 or as ((void*)0).  In C++, ((void*)0) is
> not a valid definition of NULL, because C++'s definition of "null
> pointer constant" is more strict than C's.

True.  My point was just an example of how NULL could be defined so that 
the code that Melzzzzz thought would not compile, could be valid.

> 
>      A *null pointer constant* is an integer literal with value zero
>      or a prvalue of type std::nullptr_t. A null pointer constant
>      can be converted to a pointer type; the result is the *null
>      pointer value* of that type and is distinguishable from every
>      other value of object pointer or function pointer type.
> 
> (In C++11 and earlier, a integral constant expression with value
> 0 could be a null pointer constant, but C++14 restricted this to
> integer literals.  ((void*)0) hasn't been a valid C++ null pointer
> constant going back at least to C++98.)

Yes.  In C, "((void*) 0)" is a common definition for NULL because it is 
more expressive and restrictive in its valid uses than 0.  In C++, 
"nullptr" is typically used now, with "0" being the only  (AFAIK) 
portable definition that is valid in many C and C++ standards.

Particular compilers can, of course, have their own definitions.  Many 
gcc installations define it as __null.

> 
> But yes, NULL might be usable in a context that requires an integer
> value depending on how the implementation defines it.  Of course it
> would be silly to depend on that.
> 

Agreed.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web