Memory corruption on freeing a pointer to pointer

[glen herrmannsfeldt]

(snip, I wrote)

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.

It has been a long time since I wrote ALGOL. Does it allow assignment
in places, such as inside and IF, where it might be confused for
a relational expression?

One that I do remember for ALGOL is that it uses IF THEN ELSE
for the conditional operator.

I := IF J>1 THEN 3 ELSE 4;

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.

PL/I uses '0'B and '1'B, bit strings of length one. It allows
conversion beteen bit (or character) strings and numeric types,
though.

But also PL/I, like Fortran, has an assignment statement.
The = in assignment has a differnet meaning from = as a relational
operator. Multiple assignment is done with , not =.

-- glen

 

[glen herrmannsfeldt]

(snip on Fortran = operator)

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.

Even more, unlike C, subscript and substring are not operators
in Fortran. You can't subscript a function returning an array
without assigning the value to an array first.

-- glen

 

[Tim Rentsch]

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?

It's 7. Just ask Ken Iverson.

 

[James Kuyper]

On 08/28/2013 11:31 PM, Robert Wessel wrote:
....

While I don't know how the Indian census work, the U.S. census asks
about a particular day (April 1, for the 2010 census), and about
people who were living in the surveyed household on that date. So the
problem of people being born or dying during the survey is largely
eliminated (time zones present an obvious issue, for example).

While the percentage of the population that was born or died on April
1st was relatively insignificant, with a population as large as that of
the US, it's still a fair number of people. The number being counted is
still not sufficiently well-defined to justify treating all of the
digits in the total as significant.

 

[Martin Shobe]

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.

The rule under discussion is that constants should go on the right when
being compared to variables or formula that contain them. It's also in
direct response Ben saying that mathematicians tend to follow that rule.
As such, I find it a rather convincing rejoinder.

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.

Of course not, but someone was using a (supposed) mathematical
convention to justify a particular coding style.

My personal take on the issue is that the more important of the two
formulas being compared should be on the left side. On the math page in
question, pi is the important item, so it should be on the left. When
programming, the constant is rarely the more important.

Martin Shobe

 

[Ben Bacarisse]

Of course not, but someone was using a (supposed) mathematical
convention to justify a particular coding style.

That was me, but I did not want to not justify a coding style. (That
requires and assessment of pros and cons that probably won't be
universal, across projects). I was pointing out that mathematicians,
who could be relied on more than anyone to understand that 0 = x is the
same as x = 0, don't write such things any way round. There is, it
seems, a "natural" way which I suspect is related to the subject/object
asymmetry in English.

The example page contains several such examples ("the special case r=0",
"then c=0", "plugging x=1" and so on). The large formulas that Ike
pointed to are a distraction, because they are not analogous to the C
tests that sparked this sub-thread. I can't image "hence 0=x" not being
corrected by a journal editor. Of course here there is no "pro" -- no
advantage at all to writing it that way round -- only a "con" in terms
of the mental hiccup is causes.

My personal take on the issue is that the more important of the two
formulas being compared should be on the left side. On the math page
in question, pi is the important item, so it should be on the
left. When programming, the constant is rarely the more important.

That may be it, I don't know. Oddly, the object-oriented syntax
x.equal_to(0) was criticised (rightly in my view) because it is
asymmetric, but it probably matches what our brains are doing, when we
think in English, more closely than a symmetric operator does.

 

[Ben Bacarisse]

(snip on Fortran = operator)

The folks over in comp.lang.fortran have confirmed that Fortran does not
have a = operator. (I'm not saying you said there was one, but this
snip comment could be read as not disagreeing with David Thompson).

<snip>

 

[Philip Lantz]

Physics is just maths constrained by reality...

Um, have you read about String Theory?

 

[Martin Shobe]

<snip>
The example page contains several such examples ("the special case r=0",
"then c=0", "plugging x=1" and so on). The large formulas that Ike
pointed to are a distraction, because they are not analogous to the C
tests that sparked this sub-thread. I can't image "hence 0=x" not being
corrected by a journal editor. Of course here there is no "pro" -- no
advantage at all to writing it that way round -- only a "con" in terms
of the mental hiccup is causes.

I can think of three (two legitimate) reason why "hence 0=x" wouldn't be
"corrected" off the top of my head.

1) "0" is either being defined, or we are listing formulas that are
equal to zero. (Similar to the example page.)

2) It comes at the end of a sequence of equations where the 0 was
derived from the left hand side of the previous equations.

3) The editor missed it.

That may be it, I don't know. Oddly, the object-oriented syntax
x.equal_to(0) was criticised (rightly in my view) because it is
asymmetric, but it probably matches what our brains are doing, when we
think in English, more closely than a symmetric operator does.

Or maybe we are just used to seeing it as an operator rather than a
function call. I can't say I'm particularly fond of equal_to(x, 0) either.

Martin Shobe

 

[Ben Bacarisse]

I can think of three (two legitimate) reason why "hence 0=x" wouldn't
be "corrected" off the top of my head.

1) "0" is either being defined, or we are listing formulas that are
equal to zero. (Similar to the example page.)

Yes, I covered that case in my original message, but I didn't think to
repeat it. It's really not a special case. 0 is simply the symbol
being constrained by the condition, just a x is in the more usual case.

2) It comes at the end of a sequence of equations where the 0 was
derived from the left hand side of the previous equations.

Maybe. Not sure I like it even in this case. Without the "hence" I
think it's more likely to be left alone.

3) The editor missed it.

<snip>

 

[David Thompson]

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.

(Confirmed elsethread) you're right. Sorry, brainslip.

 

[David Thompson]

(snip, I wrote)



It has been a long time since I wrote ALGOL. Does it allow assignment
in places, such as inside and IF, where it might be confused for
a relational expression?

There were two algols, rather different. algol 60 could be thought of,
very roughly, as a nicer syntax for nearly Fortran semantics plus
call-by-name (which proved a pretty spectacular dead-end). algol 68
was an attempt, partly successful, to combine nearly all known
semantics into one rather minimalist syntax, philosophically a bit
like LISP. Except for declarations, pretty much everything functioned
as an expression (although not always called that) and (unless my
memory is playing tricks again) that includes using at least a boolean
assignment -- as I hinted, I don't recall for sure about other types
-- as a value and thus a predicate.

One that I do remember for ALGOL is that it uses IF THEN ELSE
for the conditional operator.

I := IF J>1 THEN 3 ELSE 4;

Either keywords IF THEN ... FI *or* symbols ( | |: ). Similarly for
loops and most other things. The keywords are more readable (if you
know English) but the symbols are more math-y and international.

 

[glen herrmannsfeldt]

(snip, I wrote)

There were two algols, rather different. algol 60 could be thought of,
very roughly, as a nicer syntax for nearly Fortran semantics plus
call-by-name (which proved a pretty spectacular dead-end). algol 68
was an attempt, partly successful, to combine nearly all known
semantics into one rather minimalist syntax, philosophically a bit
like LISP. Except for declarations, pretty much everything functioned
as an expression (although not always called that) and (unless my
memory is playing tricks again) that includes using at least a boolean
assignment -- as I hinted, I don't recall for sure about other types
-- as a value and thus a predicate.

I used to have an Algol 58 book near my computer, but not now.

Either keywords IF THEN ... FI *or* symbols ( | |: ). Similarly for
loops and most other things. The keywords are more readable (if you
know English) but the symbols are more math-y and international.

Some years ago, I used ALGOL-10 on the PDP-10. I don' t know that
I had a manual for it, though, so I might not have known all the
features.

-- glen