The void** pointer breaking symmetry?

[Keith Thompson]

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.

 

[CBFalconer]

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

 

[Keith Thompson]

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

 

[elmar]

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

 

[Richard Heathfield]

(e-mail address 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.

 

[Flash Gordon]

(e-mail address 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.

 

[Richard Bos]

(e-mail address 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

 

[CBFalconer]

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:
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

 

[Richard Heathfield]

CBFalconer said:

But I won't give up goto.

Remember the steps, mate!

 

[RSoIsCaIrLiIoA]

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