Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > The void** pointer breaking symmetry?

Reply
Thread Tools

The void** pointer breaking symmetry?

 
 
Keith Thompson
Guest
Posts: n/a
 
      05-10-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
[...]
> In short: checking if a pointer is NULL is one of the most frequent
> pointer-related tasks. If NULL is actually 0, that compiles to
> something equivalent to "test eax,eax", otherwise it ends up as "cmp
> eax,SOME_LONG_BITPATTERN", which gives about 5 (32bit) to 7 (64bit)
> times the code size. This is the evolutionary pressure that makes the
> NULL choice non-arbitrary, contrary to what is claimed in the FAQ.


Surely a machine on which the most natural representation for a null
pointer is something other than all-bits-zero will have a simple way
to compare a pointer against that value. Perhaps even a dedicated
test_null_pointer instruction.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      05-10-2006
Keith Thompson wrote:
>

.... snip ...
>
> A labelled break, that breaks out of a loop specified *by name*,
> would be a great idea, one that I've advocated before.


We've got one. It's called a 'goto'. Works quite nicely.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>


 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      05-11-2006
CBFalconer <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>>

> ... snip ...
>>
>> A labelled break, that breaks out of a loop specified *by name*,
>> would be a great idea, one that I've advocated before.

>
> We've got one. It's called a 'goto'. Works quite nicely.


Yes, as I mentioned in a paragraph that you snipped.

The problem is that it works *too* well. I still want an explicit
labelled break; I've found it very useful in languages that support
it.

Any arguments that goto is just as good as a labelled break apply
equally well to the existing single-level break (except for the very
real and valid argument that single-level break already exists in the
language). (And yes, this is arguably off-topic.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
elmar@cmbi.ru.nl
Guest
Posts: n/a
 
      05-11-2006
Keith Thompson wrote:
> (E-Mail Removed) writes:
> [...]
> > In short: checking if a pointer is NULL is one of the most frequent
> > pointer-related tasks. If NULL is actually 0, that compiles to
> > something equivalent to "test eax,eax", otherwise it ends up as "cmp
> > eax,SOME_LONG_BITPATTERN", which gives about 5 (32bit) to 7 (64bit)
> > times the code size. This is the evolutionary pressure that makes the
> > NULL choice non-arbitrary, contrary to what is claimed in the FAQ.

>
> Surely a machine on which the most natural representation for a null
> pointer is something other than all-bits-zero will have a simple way
> to compare a pointer against that value. Perhaps even a dedicated
> test_null_pointer instruction.


I thought about that, including the additional silicon required for a
dedicated instruction, as well as an additional set_pointer_to_null
instruction etc.

Funnily however, here's the complete FAQ piece for the Prime 50:

"The Prime 50 series used segment 07777, offset 0 for the null pointer,
at least for PL/I. Later models used segment 0, offset 0 for null
pointers in C, necessitating new instructions such as TCNP (Test C Null
Pointer), evidently as a sop to all the extant poorly-written C code
which made incorrect assumptions."

(I'm not sure about the logic behind this statement, i.e. what TCNP
actually did (maybe test against 0:0 and 07777:0 in one shot?), but it
shows the point: being forced to finish their work quickly, people take
shortcuts where possible (some more, some less justified . They
generate billions of lines of codes, and if *afterwards* someone
designs a new architecture, he'll think twice before breaking a
significant portion of the existing code base, e.g. by messing with
NULL or introducing pointers of different size. And he'll certainly
never make an arbitrary choice like 07777 again. Richard said that it
happened in the past, so it can happen again. I think the fact that the
only examples in the FAQ are >20 years old and from the early days of C
either indicates that the FAQ is now equally old - or gives a hint that
in the mean time, the pressure of the existing code base has grown so
large that noone ever dared to do it again...

Greetings,
Elmar

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      05-11-2006
(E-Mail Removed) said:

> They
> generate billions of lines of codes, and if *afterwards* someone
> designs a new architecture, he'll think twice before breaking a
> significant portion of the existing code base, e.g. by messing with
> NULL or introducing pointers of different size.


[Some Microsoft application groups] "...thought they had good reason for
thinking they could safely use +2 instead of +sizeof(int). Microsoft writes
its own compilers, and that gave programmers a false sense of security. As
one programmer put it a couple of years ago, 'The compiler group would
never change something that would break all of our code.' That programmer
was wrong. The compiler group changed the size of ints (and a number of
other things) to generate faster and smaller code for Intel's 80386 and
newer processors. The compiler group didn't want to break internal code,
but it was far more important for them to remain competitive in the
marketplace. After all, it wasn't their fault that some Microsoft
programmers made erroneous assumptions." - Steve Maguire, former Microsoft
programmer.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      05-11-2006
Richard Heathfield wrote:
> (E-Mail Removed) said:
>
>> They
>> generate billions of lines of codes, and if *afterwards* someone
>> designs a new architecture, he'll think twice before breaking a
>> significant portion of the existing code base, e.g. by messing with
>> NULL or introducing pointers of different size.

>
> [Some Microsoft application groups] "...thought they had good reason for
> thinking they could safely use +2 instead of +sizeof(int). Microsoft writes
> its own compilers, and that gave programmers a false sense of security. As
> one programmer put it a couple of years ago, 'The compiler group would
> never change something that would break all of our code.' That programmer
> was wrong. The compiler group changed the size of ints (and a number of
> other things) to generate faster and smaller code for Intel's 80386 and
> newer processors. The compiler group didn't want to break internal code,
> but it was far more important for them to remain competitive in the
> marketplace. After all, it wasn't their fault that some Microsoft
> programmers made erroneous assumptions." - Steve Maguire, former Microsoft
> programmer.


A real instance of something from years ago coming back in to vogue and
breaking code. Once upon a time, back int he days of the 8086, pointers
were not always the same size as int, sometimes they were larger, so you
could not store a pointer in an int and manipulate it. Years passed and
"all" systems did the obvious thing of making pointers and ints the same
size. People wrote code that assumed this. More years have passed and
now we have 64 bit systems where a pointer can be larger than an int
thus breaking code that assumes it can store a pointer in an int.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      05-11-2006
Flash Gordon <(E-Mail Removed)> wrote:

> Richard Heathfield wrote:
> > (E-Mail Removed) said:
> >
> >> They
> >> generate billions of lines of codes, and if *afterwards* someone
> >> designs a new architecture, he'll think twice before breaking a
> >> significant portion of the existing code base, e.g. by messing with
> >> NULL or introducing pointers of different size.

> >
> > [Some Microsoft application groups] "...thought they had good reason for
> > thinking they could safely use +2 instead of +sizeof(int). Microsoft writes
> > its own compilers, and that gave programmers a false sense of security. As
> > one programmer put it a couple of years ago, 'The compiler group would
> > never change something that would break all of our code.' That programmer
> > was wrong. The compiler group changed the size of ints (and a number of
> > other things) to generate faster and smaller code for Intel's 80386 and
> > newer processors. The compiler group didn't want to break internal code,
> > but it was far more important for them to remain competitive in the
> > marketplace. After all, it wasn't their fault that some Microsoft
> > programmers made erroneous assumptions." - Steve Maguire, former Microsoft
> > programmer.

>
> A real instance of something from years ago coming back in to vogue and
> breaking code. Once upon a time, back int he days of the 8086, pointers
> were not always the same size as int, sometimes they were larger, so you
> could not store a pointer in an int and manipulate it. Years passed and
> "all" systems did the obvious thing of making pointers and ints the same
> size. People wrote code that assumed this. More years have passed and
> now we have 64 bit systems where a pointer can be larger than an int
> thus breaking code that assumes it can store a pointer in an int.


Cue also the lParam/wParam debacle.

Richard
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      05-11-2006
Keith Thompson wrote:
> CBFalconer <(E-Mail Removed)> writes:
>> Keith Thompson wrote:
>>>

>> ... snip ...
>>>
>>> A labelled break, that breaks out of a loop specified *by name*,
>>> would be a great idea, one that I've advocated before.

>>
>> We've got one. It's called a 'goto'. Works quite nicely.

>
> Yes, as I mentioned in a paragraph that you snipped.
>
> The problem is that it works *too* well. I still want an explicit
> labelled break; I've found it very useful in languages that support
> it.
>
> Any arguments that goto is just as good as a labelled break apply
> equally well to the existing single-level break (except for the very
> real and valid argument that single-level break already exists in the
> language). (And yes, this is arguably off-topic.)


No, I think it is a matter of style.

I agree with your points, and disagree with your conclusions. I
would be willing to dispense with break entirely, were it not for
the case anamoly. continue I find useful to mark empty statements,
as in:

while (whatever) continue;

But I won't give up goto.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html


 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      05-11-2006
CBFalconer said:
>
> But I won't give up goto.


Remember the steps, mate!

--
Richard Heathfield
You kinda have to have seen "Finding Nemo" to get this...
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
RSoIsCaIrLiIoA
Guest
Posts: n/a
 
      05-15-2006
On Sat, 06 May 2006 13:21:21 -0400, Eric Sosman
<(E-Mail Removed)> wrote:
> Even the cast will not save you. Just as numbers come in
>different flavors, pointers come in different flavors. Just as
>you cannot set a number to zero without knowing its type, you
>cannot set a pointer to NULL without knowing its type.


if i know the *size* i can set the number to zero
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pointer to pointer or reference to pointer A C++ 7 07-05-2011 07:49 PM
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Looking for a breaking news rss feed that really contains breaking news Amy XML 0 02-22-2005 06:31 PM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM



Advertisments