Memory corruption on freeing a pointer to pointer

[Ike Naar]

True -- but I've seen programmers who habitually use "Yoda
conditions" even in cases where they're not necessary. I suppose
cultivating the habit of putting the constant on the left, without
necessarily thinking each time about whether it's necessary, does
avoid "=" vs. "==" problems.

There might be a non-habitual reason for putting the constant on
the left. One can be non-dogmatic about the order of the operands
for the == operator just as one can be non-dogmatic about their
order in case of, say, the '+', the '*' or the '|' operators.

 

[Phil Carmody]

If all our pointers we called "ptr", I'd probably have less problem
with "if (ptr)".

What I do find jarring (and often incorrect) is "if (cond == true)".

That's a subtle one. It doesn't look disgusting (so doesn't "jar",
/per se/), but it definitely stands out as another one of those
tell-tale signs that foretell /hic erunt plures dracones/.
Next time I'm at my work machine, I'll check the file I was
looking at the other day, to see if they do that or similar.

Phil

 

[Phil Carmody]

<http://en.wikipedia.or/wiki/English_language#Geographical_distribution>

And of course everything on that page is absolutely completely correct -
I mean, the authors even know the population of India to 10 significant
digits! That's like knowing the radius of the earth to millimetre accuracy!

Phil

 

[Phil Carmody]

On 08/28/2013 03:39 AM, David Brown wrote: ....
During that time I met people from all over the British Commonwealth,
speaking a variety of dialects (now that I think about it, I don't
recall meeting any Scots, which seems odd). No one was impolite enough
to express anti-US sentiments while I was around (as one of them pointed
out to me ). However, I was surprised to hear several of them
express strong prejudices based upon the differences between English
dialects from places separated by no more than few hundred kilometers,
such as York and London.

I can name at least half dialects between those extremely distant places!

And express strong prejudices about all of them!!

It seemed to me that, while all of the British dialects shared common
differences in grammar and vocabulary from US English, that the
difference in pronunciation between US English and the Queen's English
was much smaller than the differences between the various British dialects.

Absolutely. But I can still express strong prejudices about it
(but it's plural, the 4 corners are all fairly distinct)!

I like Ian, so he's off the hook

Phil, ensuring he satisfies all obligatory prejudices.

 

[Keith Thompson]

So, for the '+' operator it may depend on context,
Yes.

but for the '==' operator it should depend on dogma?

For me, it depends on which form I personally find less awkward,
which happens to be the form with the constant on the right.

 

[Phil Carmody]

So, for the '+' operator it may depend on context,
but for the '==' operator it should depend on dogma?

It's not dogma, it's convention. I am familiar with
the reasons why others adopt a different convention,
and I find their reasons weak.

What's 1 + 2 * 3?

I adamantly support the convention that it is 7, but
there are some who can quite justifiably claim it's 9.
I find their convention inferior. I am in the majority.
That doesn't make it dogma.

Phil

 

[Keith Thompson]

There might be a non-habitual reason for putting the constant on
the left. One can be non-dogmatic about the order of the operands
for the == operator just as one can be non-dogmatic about their
order in case of, say, the '+', the '*' or the '|' operators.

You keep using the word "dogma" when "preference" or "convention"
would IMHO be more accurate.

I see no reason to *prefer* putting the constant on the left other than
avoidance of "=" vs. "==" problems.

From your point of view, I would expect that consistently putting the
constant on the left would be no better or worse than consistently
putting it on the right.

 

[Keith Thompson]

<http://en.wikipedia.org/wiki/English_language#Geographical_distribution>

[corrected URL]

And of course everything on that page is absolutely completely correct -

I don't recall anyone claiming that it was.

I mean, the authors even know the population of India to 10 significant
digits! That's like knowing the radius of the earth to millimetre accuracy!

The page cites the 2001 census, which presumably reported the
figures in that manner. I'm sure the census wasn't actually that
precise (if nothing else, people were born and died while the census
was in progress), but it would be very difficult (and beyond the
scope of that article) to determine just how precise it really is.
It seems reasonable to quote the raw figures rather than arbitrarily
replacing the last N digits by zeros.

 

[James Kuyper]

And of course everything on that page is absolutely completely correct -

I don't know of any source of information with those characteristics,
and I wouldn't dream of thinking that this was such a source. Do you
know of any such source?

I mean, the authors even know the population of India to 10 significant
digits! ...

Wikipedia isn't responsible for those numbers or their accuracy or
precision; it's only responsible for choosing appropriate authorities,
and providing citations, which it has. In this case, the authority is
the Indian 2001 Census. If you have objections to that number, contact
the people who published that Census. The actual Census report should
clearly identify what they think the accuracy of this figure was, and it
shouldn't claim that it was accurate to the last digit.

On the other hand, the Indians I've known have uniformly criticized the
corruption of their own government - it's possible that the Census
report was produced by political hacks who knew little or nothing about
statistics, in which case I wouldn't even trust the first significant digit.

Only if the citation is incorrect, or selected from an inappropriate
authority, do you have any basis for criticizing Wikipedia. Do you think
that the Indian Census is an inappropriate authority? Do you have reason
to believe that this is not the correct number from that census report?

 

[James Kuyper]

I can name at least half dialects between those extremely distant places!

As they say: "In America, 100 years is a long time. In Britain, 100
miles is a long distance."

 

[glen herrmannsfeldt]

(snip)

It's not dogma, it's convention. I am familiar with
the reasons why others adopt a different convention,
and I find their reasons weak.

What's 1 + 2 * 3?

Many characteristics of our favorite programming languages
trace back to Fortran. (One of the biggest, multiple character
variable names, still hasn't been adopted by mathematics.)

It does make sense that the original FORmula TRANslation
adopted the associativity and precedence rules used in
algebra. (Though it was a long time before Fortran allowed
for associativity in exponentiation.)

I adamantly support the convention that it is 7, but
there are some who can quite justifiably claim it's 9.
I find their convention inferior. I am in the majority.
That doesn't make it dogma.

Some hand calculators don't have enough logic to keep track
of such. A few programming languages also don't follow the
usual conventions. One interesting one that doesn't is PL/360.

-- glen

 

[Ian Collins]

Absolutely. But I can still express strong prejudices about it
(but it's plural, the 4 corners are all fairly distinct)!

I like Ian, so he's off the hook

Phew, what a relief!

When I first came to live down here, the greatest compliment I was paid
was "you don't sound like a Pom"!

 

[Ike Naar]

If (X==Y) is jarring and unnecessary, then, for symmetry reasons
(Y==X) is unnecessary and jarring.

That sounds like a quasi-mathematical argument, but mathematicians don't
do this. I can't recall ever seeing "let 0 = x" or "for all 2 < x" in a
maths paper[*] (it may have happened but the rarity is the thing). The
only place where it occurs with any frequency in the rather natural
notation for a range: "0 < x < 1". Mathematicians know that it is hard
enough to read the damn stuff, without the author throwing up
road-blocks in the way. We, as programmers, are in the same boat.

In many places where I've seen the construct "let X = Y" it's used
to introduce the name X as a placeholder for expression Y, not to
express the equality of expressions X and Y.
Definitions are not symmetric, and some authors use an asymmetric
operator like ':=' instead of '=' for this reason.

I just re-visited a popular mathematical web page [*] that happens
to be in my bookmark list, and noticed it has quite a lot of
equations with a constant on the left hand side.
Notice, in particular, how equation (73) has the constant the right
hand side, where equation (74) has the same constant on the left
hand side of the equality operator. Neither of these equations
looks jarring (to me).

[*] http://mathworld.wolfram.com/PiFormulas.html

 

[Ike Naar]

From your point of view, I would expect that consistently putting the
constant on the left would be no better or worse than consistently
putting it on the right.

Indeed.

 

[Malcolm McLean]

Indeed.

The right side of your visual field goes to the left hemisphere first, the
left side to the right. So actually changing the order changes the way
we process the information. That's why languages which use the root
consonant system are written right-left, whilst languages which use the
prefix-stem-suffix system are written left-right. In the former, you want
to see the root before you decipher the word, in the latter it's more
linear.

 

[Keith Thompson]

I just re-visited a popular mathematical web page [*] that happens
to be in my bookmark list, and noticed it has quite a lot of
equations with a constant on the left hand side.
Notice, in particular, how equation (73) has the constant the right
hand side, where equation (74) has the same constant on the left
hand side of the equality operator. Neither of these equations
looks jarring (to me).

[*] http://mathworld.wolfram.com/PiFormulas.html

The constant in question is pi (written as the Greek letter which I
won't reproduce here for the sake of primitive newsreader software).

Equation 74 is, roughly:

pi = sqrt(6 * ( 1 + ... ) )

Yes, pi is a mathematical constant, but that equation is not the same
kind of thing you'd see in a C if statement. It's almost a definition
of pi. More precisely, it's a way to compute its value, almost but not
quite analogous to a C assignment rather than to an "==" equality
comparison. ("==" asks whether two expressions are equal; a
mathematical equation *asserts* that they're equal.)

It makes perfect sense, even to me, to put the constant on the left side
-- for reasons that don't apply to `if (NULL == ptr)` in C.

As for equation 73, it's of the form:

[formula] = [another formula] = pi

and it appears (if I understand it) to be a left-to-right derivation, so
the order is logically significant, at least to a human reader.

TL;DR: Mathematical equations are not C equality tests.

 

[David Thompson]

Since when?

F90. But .EQ. and friends remain also available (and fill the dusty
decks off to the horizon, or something like that).

As I believe glen noted elsethread, there's no ambiguity in Fortran
because it allows assignment only as a (top-level) statement not a
(nestable) expression.

 

[David Thompson]

Now, Java came up with another solution to this problem.
The expression in if must have type boolean, and, except in
the case of assignment to a boolean variable, and assignment
won't be boolean, the assignment won't compile.

Java didn't invent this; algol68 has a distinct boolean type (although
I don't recall if this case is coercible) and does have nestable
assignment, but (canonically) using := which is harder to mistake.

Fortran>=77 also has boolean, as do Pascal and Ada, but they have (as
you noted) assignment as a statement not a (sub)expression, plus the
latter two use := . I don't know about the other Wirth languages.

The only non-C-family language I know to use integer 1/0 for boolean
is APL. FORTH uses integer nonzero/0 with a preference for -1 as the
nonzero, but FORTH is almost as typeless as BCPL, plus the syntax for
both assignment and if are radically different from C.

 

[David Thompson]

I know what !strcmp(s1, s2) means, but I dislike it.

Many functions return a logically Boolean result, even if the result
isn't of type bool or _Bool. By "logically Boolean", I mean that
the result answers a yes/no question without adding more information.

strcmp is not one of those functions, so I dislike using its result
either as a condition or as the operand of "!". For much the same
reason, I dislike writing "if (ptr)" and strongly prefer "if (ptr != NULL)".

I agree on strcmp, partly because it's ternary (as you note
downthread) but I think mostly because 'compare' doesn't connote to me
which case is true. If it had been named strunequal or strdifferent --
still returning 0 for equal and >0 or <0 for the two different types
of unequal -- I would be happy to write it as a pseudo-boolean in the
cases where I only care about equal/unequal, which I estimate is well
over half, and write the >0 or <0 only when I care about direction.
But those names would have been too long in PDP-11 days; strdiff works
for me about as well as memcpy, but struneq just looks silly.

OTOH I disagree about pointers. Maybe it's a fair bit of LISPing, but
the first attribute I think of about almost any pointer, regardless of
target type, is possible nullness. I find ptr or !ptr natural, but I'm
also fine with !=NULL and ==NULL if the style uses that.

But of course that wasn't the point of the question. Using a different
example, would you even consider writing

if (5 == strlen(s))

rather than

if (strlen(s) == 5)

if it weren't for the "==" vs. "=" issue?

Probably not for a simple case like that, and the first 2 or 3 times I
read such it did slow me up a bit before I got used to it.

But if s is more complicated -- maybe if enough to put the ==5 way to
the right and definitely if enough to put it on a subsequent line -- I
would be much more likely to keep the 5 'up front'. OTOH in those
cases I might consider doing the complicated part in a separate
assignment and reducing it to the simple case -- at least for if;
comparable cases in while and for are harder.

 

[Ben Bacarisse]

F90. But .EQ. and friends remain also available (and fill the dusty
decks off to the horizon, or something like that).

As I believe glen noted elsethread, there's no ambiguity in Fortran
because it allows assignment only as a (top-level) statement not a
(nestable) expression.

I can't get gfortran to accept it, and I can't find it in the 2008 draft
standard (the first one I could find for no money). == yes, that's been
around for some time.