Memory corruption on freeing a pointer to pointer

[Keith Thompson]

(e-mail address removed) writes: [...]
Your quoted text is still double-spaced; see above.



This is the fault of the broken Google Groups interface (years of

complaints have not prompted Google to fix this), but you should be

able to avoid the problem. Either delete the blank lines yourself,

or use an Usenet interface other than Google Groups.

i don't see that on my end. your post are double spaced.

My post was not double spaced. Your quotation of my post is.

As an experiment, I started to compose a followup in Google Groups.
I could clearly see that the double-spaced quoted text, and I was
able to clean it up by copy-and-pastiung the text into an editor,
fixing it, and copy-and-pasting it back.

 

[James Kuyper]

....
i don't see that on my end. your post are double spaced.

When I look at this thread using Google Groups:

The original message from Sharwan Joram,
<https://groups.google.com/d/msg/comp.lang.c/jtP__M9Xd9o/fW2zlPTbxD4J>,
is single spaced.

The response by gdotone,
<https://groups.google.com/d/msg/comp.lang.c/jtP__M9Xd9o/r-XrYY2IueYJ>
contains text quoted from the previous message, which is double-spaced.

The response by Keith Thompson,
<https://groups.google.com/d/msg/comp.lang.c/jtP__M9Xd9o/8gkzz3A1GtIJ>
is single spaced.

The response by gdotone,
<https://groups.google.com/d/msg/comp.lang.c/jtP__M9Xd9o/JZCt8zLOCgkJ>
contains text quoted from Keith Thompson, which is double spaced.

The response by Keith Thompson,
<https://groups.google.com/d/msg/comp.lang.c/jtP__M9Xd9o/LiTdf7b55DsJ>
contains the text from Keith's previous message that was quoted by
gdotone, retaining the double-spacing that was introduced by gdotone's
message.

The response by gdotone,
<https://groups.google.com/d/msg/comp.lang.c/jtP__M9Xd9o/LgP6PBT6BzsJ?
contains text quoted from Keith's 2nd message. Since that message
contains double-spaced text quoted from Keith's first message, it is now
quadruple-spaced.

Do you see any double-spacing in any of those messages other than what
I've described above? Notice that in every case, your use of Google
Groups to respond with quoted text was the source of the double-spacing.
If you must use Google Groups, please remove the spurious extra space it
introduces; but you'd be better off using the alternatives he mentions.

 

[gdotone]

(e-mail address removed) writes:

[...]

Your quoted text is still double-spaced; see above.



This is the fault of the broken Google Groups interface (years of

complaints have not prompted Google to fix this), but you should be

able to avoid the problem. Either delete the blank lines yourself,

or use an Usenet interface other than Google Groups.

i don't see that on my end. your post are double spaced.

My post was not double spaced. Your quotation of my post is.



As an experiment, I started to compose a followup in Google Groups.

I could clearly see that the double-spaced quoted text, and I was

able to clean it up by copy-and-pastiung the text into an editor,

fixing it, and copy-and-pasting it back.



--

Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>

Working, but not speaking, for JetHead Development, Inc.

"We must do something. This is something. Therefore, we must do this."

-- Antony Jay and Jonathan Lynn, "Yes Minister"

wait, i'm confused.

i am using googles groups web interface.
you are telling me, that when i post it is double spacing, because of something in GG's interface. ok.

but, when i copy an paste into it. it looks close to what i typed in the Xcode editor. when i look at my
postings, after summiting, there is no odd spacing.
when i reply to a post the text that i see is double space with arrows.
if you don't mind send me a screen shot of what you are seeing.

 

[gdotone]

ok, i see what you are saying, writing.

 

[glen herrmannsfeldt]

On 08/26/2013 02:40 AM, Ike Naar wrote:
(snip)

Yes, it matters - because it's intended to protect against the typo
which replaces == with =, by ensuring that it would cause a constraint
violation. The assignment operator is very definitely not symmetric.

Well, don't do that.

There are an infinite number of ways you can code C incorrectly,
and this is one.

There is a general rule that you should write for readability,
and as common mathematical English phrasing normally doesn't
work that way, it is more difficult to read.

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.

It isn't possible to change C now, but to me readability is
important, and in many cases it sounds wrong backwards.

-- glen

 

[glen herrmannsfeldt]

On 08/26/2013 10:08 AM, David Brown wrote:

(snip)

Yes, I was just thinking about Yoda.

(snip)

The code, as such, is neither forwards nor backwards. The idea that
there's a preferred order to the arguments of == has nothing to do with
any aspect of C itself; it seems to be based in linguistic preferences.
I share those preferences, but I wouldn't elevate them to issues of code
correctness, by calling the other order "backwards". I wouldn't be
surprised to find that people whose native language is not English might
find the "backwards" order more reasonable.

Reminds me of wondering why so many programming languages use
English keywords.

Seems to me that there might be some programming languages that do
assignment left to right, though most do it right to left.

It seems that both orders are used for assmeblers (and often
the corresponding machine instructions) for MOVE and other
data movement instructions.

So, yes, I would not be surprised to see a different order for
non-native English speakers, or non-English speakers coding C,
or other programming languages.

-- glen

 

[glen herrmannsfeldt]

(big snip)

I know why Yoda conditions are used, and it's a valid reason.
But would you even consider writing

if (0 == strcmp(s1, s2))

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

No, I would write

if( ! strcmp(s1, s2))

Talking about symmetry in operations, it still bothers me to write

if(s1.equals(s2))

in Java, which seems to make s1 and s2 very unequal. The symmetry
of the == operator is lost.

-- glen

 

[James Kuyper]

Well, don't do that.

If you know how to eliminate (not just reduce) errors created when
writing C (or anything else, for that matter), I'd appreciate hearing
about how it was done. If you have time for that - the secret to doing
something like that could make you very rich, if handled properly.

I don't know any such secret - so instead I use methods designed to
minimize the number of mistakes I make (which don't work very well). The
single most effective such method I've developed is to always write
bookend code (for instance, '(' and ')', or '{' and '}', or 'fopen()'
and 'fclose()') first, and then fill in what happens between the
bookends second. I almost never make "missing bookend" errors anymore.

I also use methods to ensure that most of mistakes I actually make get
caught (which works significantly better, though not as well as I'd
like). Yoda conditionals are one such method, though not one I've
decided to adopt. I agree that I find it uncomfortable - but I'd not
criticize anyone for feeling differently about that.

 

[Keith Thompson]

wait, i'm confused.

i am using googles groups web interface. you are telling me, that
when i post it is double spacing, because of something in GG's
interface. ok.
Yes.

but, when i copy an paste into it. it looks close to what i typed in
the Xcode editor. when i look at my postings, after summiting, there
is no odd spacing. when i reply to a post the text that i see is
double space with arrows. if you don't mind send me a screen shot of
what you are seeing.

Your original text is not double spaced. Any text you quote from other
articles is. It shouldn't be; that's a bug / misfeature in Google
Groups.

Not a screenshot, but a plain text copy of your article saved from my
newsreader:

https://gist.github.com/Keith-S-Thompson/6344333

Usenet works best with plain text with lines, no longer than 72 or 80
columns, delimited by explicit end-of-line characters.

Google Groups seems to assume plain text with line breaks marking
paragraph boundaries.

The best solution is to stop posting through Google Groups. The
second-best solution is to fix the damage GG does before posting.

 

[Keith Thompson]

(big snip)




No, I would write

if( ! strcmp(s1, s2))

Again, this is a matter of personal taste.

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

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?

My point is that, as far as I can see, there is no reason to put a
constant expression on the LHS of an "==" comparison and a non-constant
expression on the RHS other than the attempt to avoid a potential "=="
vs. "=" error. And *in my opinion* that's not a good enough reason to
do it.

And if both forms are equally clear to you, that's great -- but be aware
that not everyone sees it that way.

Talking about symmetry in operations, it still bothers me to write

if(s1.equals(s2))

in Java, which seems to make s1 and s2 very unequal. The symmetry
of the == operator is lost.

I haven't done enough Java to comment on that, but at first glance I
agree that (s1.equals(s2)) isn't very pretty.

 

[Malcolm McLean]

I haven't done enough Java to comment on that, but at first glance I
agree that (s1.equals(s2)) isn't very pretty.

Virtually all object languages have that problems. The syntax makes it look
like the functions operate on one object, taking the other as an argument.
Often that doesn't express very well what the code is doing.
In C++ you can overload the == operator, but operator overloadign creates its
own issues.

 

[Ike Naar]

On 08/24/2013 03:05 PM, Sharwan Joram wrote:
[...]
if ( NULL == parameters[parametercount]){

This is what's known as a "Yoda conndition"
<http://en.wikipedia.org/wiki/Yoda_Conditions>. I know that a lot of
programmers like them, and for somewhat valid reasons, but personally I
find them jarring and unnecessary. Personally, I'd write that as:

if (parameters[parametercount] == NULL) {

Does it matter? The == operator is symmetric, (X==Y) == (Y==X).

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

[...]

Yes, it matters *to me* (and to plenty of other people). "==" is
commutative as far as the language is concerned, but code should be
written both for the compiler and for the human reader.

X==Y is a poor example for this, since X==Y and Y==X are pretty much
equally readable.

X and Y were meant to be placeholders for arbitrary subexpressions.

I prefer to treat (X==Y) as a mathematical formula (stating that
subjects X and Y have equal values), rather than shoehorn it into
an English sentence that has X, but not Y, as its subject.

How about Yodaness when both operands are non-constant, as in
(sin(alpha) == cos(beta)) ?.
Would it now matter which operand goes on the left side?

What if it's unknown which of the operands is constant?
Consider the expression (pNeedle == pHaystack).
If we assume that pNeedle is variable and pHaystack is
constant, this expression is, supposedly, perfectly readable.
But if it turns out that pNeedle is constant and pHaystack is
variable, the same expression suddenly becomes Yoda? So Yodaness
is not a syntactic property of the expression itself, but also
depends on additional knowledge that may or may not be obvious from
looking at the expression and its context, and that even may change
at runtime?

I think the main purpose of the == operator is to test whether
two values are equal. For that purpose it does not really matter
whether operands are constant or not: it's equality we're
interested in, not constness. Taking constness into consideration
just complicates things unnecessarily; so let that not influence
the way equalities are notated.

By the way, does Yodaness apply to other commutative operators as
well? Which one of (2 * f(x)) and (f(x) * 2) is Yoda, and why?

The problem (for me) is when programmers write things
like:
if (0 == strcmp(s1, s2))
rather than
if (strcmp(s1, s2) == 0)

When comparing a computed value to a constant, I'm asking a question
about the computed value: (Is it equal to this constant?) You can
ask a question about a constant: (Is it equal to this computed
value?), but I personally find that to be an awkward way to ask
the same question.

It might help to re-phrase the question to one that is more symmetric
in its operands, e.g. "are ... and ... equal?".

If you find (strcmp(s1, s2) == 0) just as readable and natural as
(0 == strcmp(s1, s2)), that's great for you; apparently your brain
works just a little bit differently than mine.

If your only criterion for choosing between two different ways
of writing something is that they have the same language-level
semantics, that should mean you have no preference between arr
and i[arr],

In this case I'd prefer arr. There is a longstanding tradition
in programming languages to write arr. C allows i[arr], but other
programming languages don't. In mathematics notation one sometimes
writes 'arr' with a subscripted 'i' to the right, but I've never
seen that the other way around.

In contrast, the equality operator is symmetric both in mathematics
and in most (every?) programming language that I know of.

or between
if (foo) {
/* ... */
}

and

if (!foo); else {
/* ... */
}

but I know which I'd rather see.

I'd prefer the first form because it's simpler.

I know why Yoda conditions are used, and it's a valid reason.
But would you even consider writing

if (0 == strcmp(s1, s2))

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

Actually the Yoda form can be slightly more readable when the
function call has a long argument list, as in

if (3 == scanf("%g %g %g", &latitude, &longitude, &elevation))

one can immediately see that the returnvalue of scanf is compared to 3,
because the 3 is close to the scanf, whereas in

if (scanf("%g %g %g", &latitude, &longitude, &elevation) == 3)

the 3 and the scanf are far apart.

 

[glen herrmannsfeldt]

(snip)
(snip, then I wrote)

Again, this is a matter of personal taste.

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

I suppose I don't especially like it, but I usually do it anyway.

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.

Yes, but == and != don't help all that much. The relation is still
backwards, but you get used to it. About as easy to get used to
with ! as with !=.

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

In this case, I think of the pointer as pointing to something, or not,
and so, to me, it makes some sense as a boolean.

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?

My point is that, as far as I can see, there is no reason to put a
constant expression on the LHS of an "==" comparison and a non-constant
expression on the RHS other than the attempt to avoid a potential "=="
vs. "=" error. And *in my opinion* that's not a good enough reason to
do it.

Yes, I don't like the

if (5 == strlen(s))

form. It looks ugly, and distracts me from reading the code.

But also I rarely do assignments in if statements.

And if both forms are equally clear to you, that's great -- but be aware
that not everyone sees it that way.

I haven't done enough Java to comment on that, but at
first glance I agree that (s1.equals(s2)) isn't very pretty.

There is also:

if("abc".equals(s1))

instead of

if(s1.equals("abc"))

which I never do, but supposedly has some advantage if s1
might be null.

-- glen

 

[glen herrmannsfeldt]

(snip, I wrote)

Virtually all object languages have that problems. The syntax
makes it look like the functions operate on one object,
taking the other as an argument. Often that doesn't express
very well what the code is doing.

In C++ you can overload the == operator, but operator
overloadign creates its own issues.

I don't know C++ quite as well, but in Java you use == to compare
the reference, .equals() to compare the object. As Java doesn't
have operator overload, you couldn't do that, but you wouldn't
want to do it anyway. Among others, you couldn't test for null.

-- glen

 

[James Kuyper]

On 08/26/2013 03:18 PM, Ike Naar wrote:
....

How about Yodaness when both operands are non-constant, as in
(sin(alpha) == cos(beta)) ?.
Would it now matter which operand goes on the left side?

Of course not - the only argument ever presented for Yoda Conditions is
protection against the possibility of mistyping = instead of ==. Such
protection is only needed when one of the operands is an lvalue; such
protection is only possible if the other is not an lvalue. It is neither
needed nor possible in this case.

What if it's unknown which of the operands is constant?
Consider the expression (pNeedle == pHaystack).
If we assume that pNeedle is variable and pHaystack is
constant, this expression is, supposedly, perfectly readable.
But if it turns out that pNeedle is constant and pHaystack is
variable, the same expression suddenly becomes Yoda? So Yodaness
is not a syntactic property of the expression itself, ...

The relevant property is lvalueness.

... but also
depends on additional knowledge that may or may not be obvious from
looking at the expression and its context, ...

If you're writing code so obfuscated that it leaves you uncertain which
expressions are lvalues, you've got bigger problems than can be dealt
with by using Yoda conditions.

... and that even may change
at runtime?

Nothing that occurs at runtime can change whether or not a given
expression is an lvalue.

I think the main purpose of the == operator is to test whether
two values are equal. For that purpose it does not really matter
whether operands are constant or not: it's equality we're
interested in, not constness. Taking constness into consideration
just complicates things unnecessarily; so let that not influence
the way equalities are notated.

By the way, does Yodaness apply to other commutative operators as
well? Which one of (2 * f(x)) and (f(x) * 2) is Yoda, and why?

Do you know of any other commutative operators for which a common typo
converts them into a different operator for which one order is a
constraint violation, and the other is perfectly legal code that does
something quite different from what it would have done without the typo?
The other operator is, of course, necessarily not commutative.

There might be some other such pair of operators - I don't claim any
certainty about that. However, but I think the ==/= typo is
overwhelmingly the most common such pair.

 

[Malcolm McLean]

On 08/26/2013 03:18 PM, Ike Naar wrote:

Do you know of any other commutative operators for which a common
typo converts them into a different operator for which one order
is a constraint violation, and the other is perfectly legal code
that does something quite different from what it would have done
without the typo?

The other operator is, of course, necessarily not commutative.

The +/= pair. They're generally on the same key, so

drawpixel(x + 2, y = 2);

is a common typo, and it's irritating that it compiles. However
unlike == / =, the difference applies to every language. Even
if you know C very well, often you don't see == / = mistakes,
whilst +/= leaps out.

 

[Keith Thompson]

On 08/24/2013 03:05 PM, Sharwan Joram wrote:
[...]
if ( NULL == parameters[parametercount]){

This is what's known as a "Yoda conndition"
<http://en.wikipedia.org/wiki/Yoda_Conditions>. I know that a lot of
programmers like them, and for somewhat valid reasons, but personally I
find them jarring and unnecessary. Personally, I'd write that as:

if (parameters[parametercount] == NULL) {

Does it matter? The == operator is symmetric, (X==Y) == (Y==X).

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

[...]

Yes, it matters *to me* (and to plenty of other people). "==" is
commutative as far as the language is concerned, but code should be
written both for the compiler and for the human reader.

X==Y is a poor example for this, since X==Y and Y==X are pretty much
equally readable.

X and Y were meant to be placeholders for arbitrary subexpressions.

Sure, but my argument (whether you agree with it or not) doesn't apply
to arbitrary subexpressions.

I prefer to treat (X==Y) as a mathematical formula (stating that
subjects X and Y have equal values), rather than shoehorn it into
an English sentence that has X, but not Y, as its subject.

How about Yodaness when both operands are non-constant, as in
(sin(alpha) == cos(beta)) ?.
Would it now matter which operand goes on the left side?

The names "alpha" and "beta" might suggest that "alpha" goes first, but
in general it probably doesn't matter -- though it might depend on the
circumstances.

What if it's unknown which of the operands is constant?
Consider the expression (pNeedle == pHaystack).
If we assume that pNeedle is variable and pHaystack is
constant, this expression is, supposedly, perfectly readable.
But if it turns out that pNeedle is constant and pHaystack is
variable, the same expression suddenly becomes Yoda? So Yodaness
is not a syntactic property of the expression itself, but also
depends on additional knowledge that may or may not be obvious from
looking at the expression and its context, and that even may change
at runtime?

Strictly speaking, constness *is* a syntactic, or at least compile-time,
property of an expression, though it's going to depend on contact
outside the expression.

I'm not sure what to make of (pNeedle == pHaystack); normally one search
for a needle *in* a haystack.

Certainly you can construct a continuum of cases, with comparing a
computed value to a literal constant on one end, and comparing the
results of two clearly symmetric expressions on the other. I admit this
is rather vague, and I don't have a well-defined rule for when the order
is important to me.

I think the main purpose of the == operator is to test whether
two values are equal. For that purpose it does not really matter
whether operands are constant or not: it's equality we're
interested in, not constness. Taking constness into consideration
just complicates things unnecessarily; so let that not influence
the way equalities are notated.

But *why* do you want to know whether they're equal? What if, in the
problem domain, what you're really doing is asking a question about the
value of some expression (is it equal to 42?), and not asking a question
about 42 (about which you already have complete knowledge)? Putting the
constant on the right can provide a useful clue to the reader.

By the way, does Yodaness apply to other commutative operators as
well? Which one of (2 * f(x)) and (f(x) * 2) is Yoda, and why?

It matters far less for multiplication. I'm not sure I can clearly
articulate why.

It might help to re-phrase the question to one that is more symmetric
in its operands, e.g. "are ... and ... equal?".

Logically true, but that doesn't make the Yoda form any clearer to me.
I know "==" is commutative, but (0 == strcmp(s1, s2)) is still clumsy
*to me*.

[snip]

Actually the Yoda form can be slightly more readable when the
function call has a long argument list, as in

if (3 == scanf("%g %g %g", &latitude, &longitude, &elevation))

one can immediately see that the returnvalue of scanf is compared to 3,
because the 3 is close to the scanf, whereas in

if (scanf("%g %g %g", &latitude, &longitude, &elevation) == 3)

the 3 and the scanf are far apart.

Ok, that's another valid reason for using Yoda conditions. I'd still put
the 3 on the right side myself; I might split it across two lines if I
thought the distance was a problem, or I might store the result in a
temporary.

But setting that aside for a moment (and avoiding the "!strcmp()"
variant):

It would never occur to me to write:
if (42 == x)
rather than
if (x == 42)
if it weren't for the possibility of confusing "==" and "=".
Would you write (42 == x) yourself? Do you really find it *just*
as natural as (x == 42)?

 

[Keith Thompson]

(snip, then I wrote)



I suppose I don't especially like it, but I usually do it anyway.


Yes, but == and != don't help all that much. The relation is still
backwards, but you get used to it. About as easy to get used to
with ! as with !=.

It helps me.

if (strcmp(s1, s2) < 0) /* s1 is less than s2 */
if (strcmp(s1, s2) == 0) /* s1 is equal to s2 */
if (strcmp(s1, s2) > 0) /* s1 is greater than s2 */
if (strcmp(s1, s2) != 0) /* s1 is not equal to s2 */
if (strcmp(s1, s2) <= 0) /* s1 is less than or equal to s2 */
...

The result returned my strcmp is not (in my head, at least)
a Boolean; it's a tri-state comparison (with all negative values
logically equivalent to each other, and all positive values logically
equivalent to each other). Which is why the only thing I'm entirely
comfortable doing with strcmp() is explicitly comparing its result
to 0.

In this case, I think of the pointer as pointing to something, or not,
and so, to me, it makes some sense as a boolean.

And the language definition agrees with you -- but it's not *just* a
Boolean. A pure Boolean value does not have multiple distinct true
values; it's true or false, nothing else.

I'm sure part of it is that I learned Pascal before I learned C.
But when I see "if (ptr)", I have to mentally translate it to
"if (ptr != NULL)".

[...]

 

[Ike Naar]

It would never occur to me to write:
if (42 == x)
rather than
if (x == 42)
if it weren't for the possibility of confusing "==" and "=".
Would you write (42 == x) yourself? Do you really find it *just*
as natural as (x == 42)?

Yes. Equality is a boolean function operating on two operands,
returning "the operands are equal". It does not matter which
one of the operands is on the left side of the operator.

 

[glen herrmannsfeldt]

(snip)

The +/= pair. They're generally on the same key, so

drawpixel(x + 2, y = 2);

is a common typo, and it's irritating that it compiles. However
unlike == / =, the difference applies to every language. Even
if you know C very well, often you don't see == / = mistakes,
whilst +/= leaps out.

Not every language. Many don't allow assignment in the middle
of expressions. In Fortran, assignment is a statement, not an
operator.

In PL/I, assignment is also a statement, and = is the relational
operator.

x,y=1; /* multiple assignment */
x=y=1; /* relational operator */

-- glen