References in C

[jacob navia]

Le 28/06/11 20:01, Tim Rentsch a écrit :

More generally, if you want to be successful in advocating
changes to the C language, it's important to hear and appreciate
the opinions and judgments of other people, even when -- or
especially when -- they don't agree with your own.

Excuse me if I offended you. I never intended to, and as far as I
remember I never insulted or say anything bad about you.

I respect of course your opinions, and I do think they are
important since I have always answered each one of your remarks.

But it is true that I am getting kind of paranoiac lately. I have
been trying to improve the language by working and working in this
community for around 20 years. The first versions of lcc-win are
from 1995, and I started working in this project around 1992. Yes,
it must be almost 20 years.

I have accomplished nothing. All my proposals were ignored and in this
group, a hate campaign started by K Thompson and R Heathfield provoked
that most people (in this group) just think I am the "shrewd commercial"
that they described.

Nevertheless I go on working. I have developed a containers library
from scratch with the idea of standardizing it. The specifications make
for around 300 pages, all the code for a sample implementation is
available.

Nothing. Not a single answer in comp.std.c. In this group some people
made positive contributions but nobody is working on that besides me.

Then, in comp.std.c somebody asks for a small improvement that I
implemented in lcc-win, and that we discussed in comp.std.c in 2002...
Almost ten years ago, and the same problem resurfaces. And I see
as in an ever repeating nightmare that nothing will ever change.

The standard is closed now, they just left a window for discussion open
for several *months* then they decided to close it. After leaving a
gap of 10 years without any discussion.

And I could go on with my "examples", but it would be unnecessary.
That is why I start getting mad/paranoiac.

jacob

 

[Ian Collins]

Le 28/06/11 20:01, Tim Rentsch a écrit :

Excuse me if I offended you. I never intended to, and as far as I
remember I never insulted or say anything bad about you.

I respect of course your opinions, and I do think they are
important since I have always answered each one of your remarks.

But it is true that I am getting kind of paranoiac lately. I have
been trying to improve the language by working and working in this
community for around 20 years. The first versions of lcc-win are
from 1995, and I started working in this project around 1992. Yes,
it must be almost 20 years.

You are pushing against a very conservative mindset. Getting any
interesting changes accepted is probably even harder since the farcical
situation with C99 where >95% of programmers use 5% of the changes and
<5% the rest.

I think the free thinkers are now working on C++. I'm sure there will
be more C++0x compilers by the end of the year than C99 compilers.

 

[Tim Rentsch]

On 06/27/11 12:53 PM, Tim Rentsch wrote:


Oh I am! Look at the proportion of posts here that relate to pointers.

I think most people don't have any problem with pointers. Most of
the confusion around pointers has to do with arrays and indexing,
and how those are all related. Adding references does nothing as
far as arrays and indexing go -- they still need to be in the
language, and still will be confusing to some people in how those
relate to pointers. If anything references would muddy the waters
because there would then be two fairly similar "pointer-like"
concepts, adding to the confusion around how arrays work.


[snip]

Humbug. You know you are passing a pointer, but you still have to
check to see if the function can modify the values it points to.

The key point is that when an argument is _not_ of pointer type then
no check need be made. With references all arguments to all
function calls would need to be checked, not just the pointer ones.

Anyway, my opinion has shifted to the "not a good idea in C" camp, so
I'll stop now.

The main purpose of my comments is not so much to state a conclusion
as it is to illustrate the process of how to judge proposals of this
sort. I think it's important to understand on which particular
points there are differences of opinion, not just that a different
conclusion was reached. So even if I might internally be happy
that you changed your stance on references in C, I think the most
value came out of getting discussion of substance on different
aspects in the cost/benefits analysis.

 

[Keith Thompson]

But it is true that I am getting kind of paranoiac lately.
Lately?

I have
been trying to improve the language by working and working in this
community for around 20 years. The first versions of lcc-win are
from 1995, and I started working in this project around 1992. Yes,
it must be almost 20 years.

I have accomplished nothing. All my proposals were ignored and in this
group, a hate campaign started by K Thompson and R Heathfield provoked
that most people (in this group) just think I am the "shrewd commercial"
that they described.

[...]

This is a prime example of your -- well, I'm not going to call
it paranoia, since that's a psychological diagnosis that I'm not
qualified to make.

I have not started or participated in any "hate campaign" against
you. I am sick and tired of the false baseless accusations you
have repeatedly made against me.

It's good to see you admit that you've been "getting kind of
paranoiac lately". I hope you'll take the next step and realize
that your personal attacks on me are the result of issues that
exist only in your own mind, not in reality.

Please take a while and *think* about this. I am not your enemy.
Stop pretending that I am.

 

[Keith Thompson]

Exactly. In my mental type map, "boolean" is a very high level abstract type,
and pointers are among its subclasses.

So a "boolean" is anything that can be used as a condition, i.e.,
anything that can be compared against 0?

Ok. I'll just say that your mental map differs from mine.

[...]

 

[Tim Rentsch]

Le 28/06/11 20:01, Tim Rentsch a @C3{A9}crit :

Excuse me if I offended you. I never intended to, and as far as I
remember I never insulted or say anything bad about you.

I wasn't offended, and I didn't feel like you were
insulting me.

I respect of course your opinions, and I do think they are
important since I have always answered each one of your remarks.

But it is true that I am getting kind of paranoiac lately. I have
been trying to improve the language by working and working in this
community for around 20 years. The first versions of lcc-win are
from 1995, and I started working in this project around 1992. Yes,
it must be almost 20 years.

I understand that you want to contribute to C, and
I applaud your desire to do that. I give my comments
in the hope that they will be constructively helpful
in providing value both to you and to the C community.

I have accomplished nothing. All my proposals were ignored and in this
group, a hate campaign started by K Thompson and R Heathfield provoked
that most people (in this group) just think I am the "shrewd commercial"
that they described.

I don't think that's right, but whether it is or not
it's important to remember that people operate on
perception, not necessarily reality. If people have
the perception that you respond to comments and feedback
in a positive and appreciative way, they are more likely
to want to give useful responses. Conversely, if people
have the perception that a reaction will probably be
personal and negative, they are more likely not to
participate in the discussion. Especially in a newsgroup
setting, all you can do is change your own behavior, and
hope other people notice that and respond positively.
Some will, and some won't, that's just life -- enjoy
the positive changes, and try not to worry about the
non-positive ones.

Nevertheless I go on working. I have developed a containers library
from scratch with the idea of standardizing it. The specifications
make for around 300 pages, all the code for a sample implementation is
available.

Nothing. Not a single answer in comp.std.c. In this group some people
made positive contributions but nobody is working on that besides me.

Then, in comp.std.c somebody asks for a small improvement that I
implemented in lcc-win, and that we discussed in comp.std.c in 2002...
Almost ten years ago, and the same problem resurfaces. And I see
as in an ever repeating nightmare that nothing will ever change.

The standard is closed now, they just left a window for discussion
open for several *months* then they decided to close it. After leaving
a
gap of 10 years without any discussion.

And I could go on with my "examples", but it would be unnecessary.
That is why I start getting mad/paranoiac.

It's important to understand two things in this regard.

The first is that the WG14 committee don't take postings in
comp.std.c as proposals to change the Standard. Oh, it's
possible some committee member would notice something here
and get all excited about it and push it ahead in committee
meetings, but it isn't very likely; they are all busy
people and have lots of other things to do. So whatever
changes you want to propose, if your goal is to get them
considered for incorporation into the Standard then
comp.std.c just isn't the right venue for that.

The second is that changes and additions to the Standard are
made on the basis of what is thought to be valuable to the C
community, and that is very much not the same as what you or I
might think is valuable. I have seen some proposals go
through that IMO are just flat out wrong, and other proposals
languish despite making a lot of sense and (again IMO)
offering a lot of value. That may not be very pleasant but
it's just how things are. The important conclusion is: If
you want to succeed in getting changes into the C standard,
__you must understand what is important to the WG14 committee
and phrase your comments and arguments accordingly__. It
doesn't matter at all whether you think something is a good
idea, or I do, or any other person reading c.s.c does; it
only matters whether people in WG14 think something is a good
idea, and that isn't going to happen unless the proposal is
made in a way that they can hear and understand and appreciate
the value of it. The biggest thing that's missing in what
you're doing is assimilating feedback about proposed features
and using that to modify exactly what it is that's proposed.
So, my suggestion is that you try to get better at hearing
feedback, and more importantly that you modify what you're
working on in response to that feedback. That will make it
far more likely that you will be able to make a contribution
to C that is valued by the C community (and hopefully also
by readers of comp.std.c).

 

[Ian Collins]

It's important to understand two things in this regard.

The second is that changes and additions to the Standard are
made on the basis of what is thought to be valuable to the C
community, and that is very much not the same as what you or I
might think is valuable.

Oh if only that were true. I do wonder how many of the "C community",
which less face it is mainly us embedded programmers these days, have
ever used all the Complex and related additions to C99. Probably a
small single digit percentage.

 

[Seebs]

Oh if only that were true. I do wonder how many of the "C community",
which less face it is mainly us embedded programmers these days, have
ever used all the Complex and related additions to C99. Probably a
small single digit percentage.

I think it's there for high performance computing people, the other
C community, and they were arguing that compilers could do a MUCH better
job than user-written libraries.

-s

 

[Seebs]

So a "boolean" is anything that can be used as a condition, i.e.,
anything that can be compared against 0?

Pretty close, for me. Well, mine's influenced by Lua and Ruby, both of
which consider integer 0 (and empty strings, for that matter) to be
logically-true. A boolean is any thing which has true and false states
as measured by an if statement. In C, that means "can be compared against
0".

I find
if (p)
MUCH clearer to read than
if (p != NULL)
in most cases. The former has a very clear predicate; a pointer, which may
or may not point. The latter has two objects and I have to think about
them. I've pretty much internalized the notion that a pointer can be
reasonably interpreted as a yes/no question.

restaurant *where_i_want_to_go_for_lunch;

if (where_i_want_to_go_for_lunch) {
...
}

Basically, I tend to perceive if (p) as "is there a..." and *p as "what is
the..."

-s

 

[Tim Rentsch]

Oh if only that were true. I do wonder how many of the "C community",
which less face it is mainly us embedded programmers these days, have
ever used all the Complex and related additions to C99. Probably a
small single digit percentage.

I believe it is true as written: "made on the basis of what
is thought to be valuable to the C community." I didn't
say who it is who are doing that thinking.

 

[Dr Nick]

Pretty close, for me. Well, mine's influenced by Lua and Ruby, both of
which consider integer 0 (and empty strings, for that matter) to be
logically-true. A boolean is any thing which has true and false states
as measured by an if statement. In C, that means "can be compared against
0".

I find
if (p)
MUCH clearer to read than
if (p != NULL)
in most cases. The former has a very clear predicate; a pointer, which may
or may not point. The latter has two objects and I have to think about
them. I've pretty much internalized the notion that a pointer can be
reasonably interpreted as a yes/no question.

restaurant *where_i_want_to_go_for_lunch;

if (where_i_want_to_go_for_lunch) {
...
}

Basically, I tend to perceive if (p) as "is there a..." and *p as "what is
the..."

I'm pretty sure I've settled on if(p) and (if p == NULL). It might be
illogical, but in one case you're saying "is p 'anything valid'" and in
the second "is p the special invalid case". Both positive tests, and I
certainly find positive tests easier to read (I really quite like
"unless" for, I think, the same reason).

 

[Michael Press]

Look at the proportion of posts here that relate to pointers.

Anyone who knows how a stored a stored program,
digital computer works has no difficulty with pointers.
A student will have trouble with pointers until
he forms a model for C's abstract machine. Some
never do. I think that C cannot be made easier
to learn.

 

[Seebs]

Anyone who knows how a stored a stored program,
digital computer works has no difficulty with pointers.

*No* difficulty?

I'm moderately optimistic that I have a pretty good basic understanding
of how pointers work at this point, but I still trip on 'em sometimes.

-s

 

[Alan Curry]

So a "boolean" is anything that can be used as a condition, i.e.,
anything that can be compared against 0?

Basically. But "can be compared against 0" is just an under-the-hood detail.
What makes a type boolean is that its values can be cleanly divided into
exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is
the only obvious way to divide pointer values into exactly 2 subsets, so
their non-null-ness is their truthiness.

Look at these examples of concise uses of pointers as booleans, taken from 3
different files in the Linux kernel:

if (drv && drv->pm && drv->pm->prepare)

if (p && p->detect && p->detect() > 0)

return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);

They look so simple. You really think it would help readability to jam a
bunch of "!= 0" or "!= NULL" noise in there?

On the other hand, floating point values aren't so clearly good for boolean
usage. You can compare them against 0, which means you can use them as
conditions, but you'll be disappointed when some theoretically false value is
actually 1e-20 and therefore true.

But maybe you have a variable that always holds a multiple of 0.5 so it can't
go near 0 without being 0. In that case I wouldn't say it's necessarily bad
to abbreviate
if(var != 0.0)
like this:
if(var)

 

[Keith Thompson]

Basically. But "can be compared against 0" is just an under-the-hood detail.
What makes a type boolean is that its values can be cleanly divided into
exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is
the only obvious way to divide pointer values into exactly 2 subsets, so
their non-null-ness is their truthiness.

Look at these examples of concise uses of pointers as booleans, taken from 3
different files in the Linux kernel:

if (drv && drv->pm && drv->pm->prepare)

if (p && p->detect && p->detect() > 0)

return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);

They look so simple. You really think it would help readability to jam a
bunch of "!= 0" or "!= NULL" noise in there?

Yes.

[...]

 

[Shao Miller]

is their truthiness.

I laughed out loud.

 

[Michael Press]

*No* difficulty?

I'm moderately optimistic that I have a pretty good basic understanding
of how pointers work at this point, but I still trip on 'em sometimes.

There is a list of storage registers holding a number.

Each storage register has an address, itself a number.

The addresses are sequential: e.g. 0, 1, 2, 3, ..., N.

The contents of a storage register can be read, and its
contents interpreted as a machine instruction and
executed.

The contents of a storage register can be interpreted
as an address, A, to fetch the contents of the storage
register at address A.

That's it. That is the only difficulty. The rest is
details and thinking straight---a chronic difficulty
for some, but not an inherent difficulty of pointers.

Likely we are thinking of different notions when using
the word "difficulty."

 

[Michael Press]

Basically. But "can be compared against 0" is just an under-the-hood detail.
What makes a type boolean is that its values can be cleanly divided into
exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is
the only obvious way to divide pointer values into exactly 2 subsets, so
their non-null-ness is their truthiness.

Look at these examples of concise uses of pointers as booleans, taken from 3
different files in the Linux kernel:

if (drv && drv->pm && drv->pm->prepare)

if (p && p->detect && p->detect() > 0)

return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);

They look so simple. You really think it would help readability to jam a
bunch of "!= 0" or "!= NULL" noise in there?

Editors and other experts in grammar and English
composition agree: when you write yourself into a
corner, then recast the sentence.

if ( drv != NULL
&& drv->pm != NULL
&& drv->pm->prepare != NULL)

if ( p != NULL
&& p->detect != NULL
&& p->detect() > 0)

return suspend_ops != NULL
&& suspend_ops->valid != NULL
&& suspend_ops->valid(state) != NULL;

 

[Seebs]

There is a list of storage registers holding a number.

Each storage register has an address, itself a number.

The addresses are sequential: e.g. 0, 1, 2, 3, ..., N.

This is not necessarily true of C. Consider the madness
of segmented architectures and the like.

The contents of a storage register can be read, and its
contents interpreted as a machine instruction and
executed.

The contents of a storage register can be interpreted
as an address, A, to fetch the contents of the storage
register at address A.

These are not necessarily generally true. There are many addresses
which can't be fetched, and it is quite easy to have a register which
can be executed but not read, or read but not executed.

That's it. That is the only difficulty. The rest is
details and thinking straight---a chronic difficulty
for some, but not an inherent difficulty of pointers.

Likely we are thinking of different notions when using
the word "difficulty."

I'm thinking "I cannot with total consistency ensure that I
never end up with a null pointer where I expected a valid pointer,
or that I never use something after freeing it", etctera.

Hmm. I haven't tried for a while, so I think I'll take this excuse to
think about my Mental Map Of Pointers.

In general, I tend to view objects in C as a giant pool of unconnected
things, which may or may not be adjacent to each other. I do not generally
have strong expectations as to which things will be adjacent to which other
things, or whether anything will be adjacent to a given thing.

A pointer refers to (some point within) one of these things. If you then
go outside the thing it refers to, you have Lost The Game. We don't know
or care what happens; don't do that. In practice, it seems that often
this will reveal that two things were, in fact, adjacent.

Code may or may not be things. It is not required to be things, but you
can make special pointers which can point to functions rather than to
things. Allocated space creates new things which are typeless until you
think about them. In principle you could then reuse space for different
types, but I pretty much never do. If I malloc() a bunch of floats, then
I view that as a bunch of floats; I don't repurpose it for something else
later, because That Would Be Crazy.

I think the big divergence is simply that I don't expect pointers into
different things to be comparable except in the equal/not-equal sense.
I don't have any particular expectation that Things can turn into Code
or vice versa; while they often can, I've used systems where attempts to
do this are doomed to failure, and this appears to have significant
technical advantages.

I also point out that not all things in C have addresses. You can have
a perfectly valid object, with a size and everything, that has no address
to take. And, of course, there is at least one address which is not the
address of any object.

-s

 

[Michael Press]

This is not necessarily true of C. Consider the madness
of segmented architectures and the like.



These are not necessarily generally true. There are many addresses
which can't be fetched, and it is quite easy to have a register which
can be executed but not read, or read but not executed.

I outlined a stored program digital computer.
You are talking about the C abstract machine,
and that is abstracted from the spdc. The similarities
are more important than the differences.

[...]

Are those details you list difficulties for you?
They are not for me, even when I get something wrong.