When to check the return value of malloc

[Nick]

Oh, sure, they were confused.

But! They could report the error to someone less confused, and the less
confused person could at least guess at what went wrong.


I have had a lot of very negative experiences involving "an unspecified
error occurred" and similar things.


True!

I my recent experience, far and away the most likely reason for malloc
to return NULL is that you have corrupted the memory pool used by
malloc. It's worth noting that Seebs' first suggested message ("memory
allocation failed" IIRC) is actually much more relevant than the
suggested alternatives involving "out of memory".

That argument that this means the developer should be told and given as
much information as possible to help them fix it remains just as strong,
if not stronger, of course.

 

[Phil Carmody]

On 5/22/2010 12:41, Tim Harig wrote:
[ snip ]

This isn't the tragedy that you might assume. You will note that many
languages do not support the ?: construct. They manage to get along fine
without it. We do as well.

And many do support it. I find it in the form 'iif(cond, this, that)'
in all of the xBase languages and in several SQL implementations. It
is easy to use, easy to understand and perfectly readable.

It can be found in the early 50s with LISP's (if condition val1 val2)
construct too.

Phil

 

[Tim Harig]

That's an exponential increase in the amount of code. Try the
same technique with:
printf("%s: %s([%s, %s])=%s, new state=%s\n",
state?state:"<no-state>",
op?op:"<no-op>",
v1?v1:"<no-v1>",
v2?v2:"<no-v2>",
res?res:"<no-result>",
newstate?newstate:"<no-state>");

1. We don't worry about programmer convenience. We worry about bug free
code. If that requires more lines, then so be it.

More lines of code can, often, result in more bugs.

This is true if one assumes a constant number of bugs per line of code. We
have found however that using our strict coding standards along with
comprehensive testing, that we our lower our bug/line ratio significantly
enough that adding extra lines of code for improved testing or for source
clarity can be justified.

So far as I can tell, this remains 100% pure handwaving. Prohibiting their
use just means someone is still checking them, and then you have a bunch
of asserts. This means that, in production, either you have completely
unchecked use of null pointers, or your software instantly crashes with
error messages meaningless to the user without any attempt at saving data.

As I have already mentioned, we avoid the direct use of pointers as
much as possible. I would have used a collection in this example.
A direct pointer need never have been used.

Neither of these is a good choice. Robust code should be checking *anyway*;
that would be the way to generate genuinely bug-free code.

We actually would provide checking to back up the assertions; however,
these checks would be located directly after the associated assertion
at the very top (and bottom) of each function where we verify all of
the functions inputs, outputs, as well as verifying that nothing input
changes that is not supposed to. This is also part of our coding
standard. For this example however, this code is merely redundant.
Should we find that the function has been given illegal inputs we know
that something is wrong in the code itself and can no longer be trusted
so the only safe action that we have is to log the error, signal
the monitor program that we need to be restarted, and abort. This is
still a bug and considered unacceptable; however, to us, a program crash
is no excuse for being unable to provide service. Program crashes are
also something that we must deal with.

There is no good way for any non-trivial program to be sure it's covered all
possible code paths during testing; as a result, you can never be sure the
asserts caught everything. Leaving them in means that your program aborts
without warning rather than making any effort at all to recover. Removing
them probably means the same thing, if you're lucky.

That is true in theory; but, something as simple as a NULL pointer being
used is too easily tested for. First, this would ve a very clear violation of
our coding standards and the program design; not to mention it would rather
odd for somebody to have entered printing code where it has no earthly
business in the program. Programs are broken into descreet modules for a
reason.

However, assuming somebody did make such a wierd decision, the first place
that it would most likely be noticed is in the code review. For a mistake
like this to happen it must pass by both programmers in the team that
created it and be signed off by a second team doing the peer review. Four
eyes should have seen this. They should seen an idiom that almost never
used and most likely somewhere that they know be design that it never
should have been.

If not, while being submitted to the revision database, it enters our unit
testing. This starts verifying all of the functions of each module from
the bottom up. Since each module is tested separately, an unplanned
dependency for the printing module in one of the modules will prevent the
tests from being able to link properly and thus fail the tests. The
revision database will then refuse to add the revision to the database and
send notification with test results back to the programmer. Even assuming
the error happens in a module that was designated to have the printer
dependency, the function is tested with against all valid inputs and dummy
functions test check any outputs or data passed to other functions. Again,
a NULL pointer passed anywhere is a big flashing neon light. Also note,
that smaller highly directed functions have less code paths to test making
coverage testing much easier.

Assuming the code passes the unit tests, it will be submitted, as a whole,
to a suite of function tests. Error conditions such as no available
printers are just the kinds of errors that we look for. Since almost every
function in our codebase aborts on receiving a NULL pointer, for this error
to pass the functional testing phase: the pointer must most likely be local to a
function and *never* be passed to another function (which violates the
black box factor of the printer_dev struct) or the offending code would
likely be in some added feature never specified by the client.

So, while it is still theoretically possible that a derefernced NULL
pointer, that should never have been used in the first place, makes it
throught all of these tests, we don't seem to have a problem with it.
The bugs that we struggle with are those which are much harder to
test for. It is much more difficult, for instance, to verify that a
non-NULL pointer is really pointing where it should be or that memory
which was allocated is properly cleaned up after an error that causes
an abortion of an incomplete operation.

 

[Tim Harig]

On 5/22/2010 12:41, Tim Harig wrote:
[ snip ]

This isn't the tragedy that you might assume. You will note that many
languages do not support the ?: construct. They manage to get along fine
without it. We do as well.

And many do support it. I find it in the form 'iif(cond, this, that)'
in all of the xBase languages and in several SQL implementations. It
is easy to use, easy to understand and perfectly readable.

It can be found in the early 50s with LISP's (if condition val1 val2)
construct too.

Nevertheless. Many languages do not provide this construct. Almost every
language provides some kind of if/else construct. If it is so vitally
important that you cannot reasonably do without it, as you guys keep
telling me, then why isn't it such a problem in other languages that do not
support it?

 

[Willem]

Tim Harig wrote:
) Nevertheless. Many languages do not provide this construct. Almost every
) language provides some kind of if/else construct. If it is so vitally
) important that you cannot reasonably do without it, as you guys keep
) telling me, then why isn't it such a problem in other languages that do not
) support it?

Could you name some languages that do not have this construct ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Nick Keighley]

On 5/22/2010 12:41, Tim Harig wrote:
[ snip ]
This isn't the tragedy that you might assume.  You will note that many
languages do not support the ?: construct.  They manage to get along fine
without it.  We do as well.
And many do support it. I find it in the form 'iif(cond, this, that)'
in all of the xBase languages and in several SQL implementations. It
is easy to use, easy to understand and perfectly readable.

It can be found in the early 50s with LISP's (if condition val1 val2)
construct too.

Nevertheless.  Many languages do not provide this construct.  Almost every
language provides some kind of if/else construct.

it's barely a programming language if it doesn't

 If it is so vitally
important that you cannot reasonably do without it, as you guys keep
telling me,

who? who said that? What I'm saying is that ?: is a legitimate part of
the language and I see no reason to avoid it if it does a useful job.
If we're removing the stuff that we can't do without, then there's
switch, break, continue, char, short, ++, +=, for (replace with
while).

The point is to put things into the language that appear to be useful
and expressive.Otherwise we might as well go back to machine code.

 

[Nick Keighley]

Tim Harig wrote:

) Nevertheless.  Many languages do not provide this construct.  Almost every
) language provides some kind of if/else construct.  If it is so vitally
) important that you cannot reasonably do without it, as you guys keep
) telling me, then why isn't it such a problem in other languages that do not
) support it?

Could you name some languages that do not have this construct ?

pascal, basic, fortran,

I'd take a look at java and python as well (I'm not sure here)

 

[Tim Harig]

Tim Harig wrote:
) Nevertheless. Many languages do not provide this construct. Almost every
) language provides some kind of if/else construct. If it is so vitally
) important that you cannot reasonably do without it, as you guys keep
) telling me, then why isn't it such a problem in other languages that do not
) support it?

Could you name some languages that do not have this construct ?

Pascal, Ada, REXX. I suspect Fortran, COBOL, and many others.

Note that some implementations of these may and that the same functionality
may be simulated using a function.

Most BCPL and by extension C derived languages do; however, Python did not
include a ternary operator until 2005 and then it is a variation of the
if/else syntax that simply allows one to assign the the value of the
if/else expression much how it is possible to assign the values of
assignments in C:

variable = if condition:
value1
else:
value2

I have *much* less problem with this as it still very clearly an if/else
branch. The only difference is that the variable is not referenced twice
in the expression:

if condition:
variable = value1
else
variable = value2

One also notes that while functionally equivilant to ?: syntax, it very
visually demonstrates just how little value a ternary operator really
provides over standard if/else syntax. In the end, its all just about not
having to type a couple of variable names and newlines.

 

[Tim Streater]

pascal, basic, fortran,

Not much cop in the language dept, these three.

 

[Willem]

Tim Harig wrote:
) variable = if condition:
) value1
) else:
) value2

That's almost exactly the same as:
variable = condition ?
value1
:
value2;

Except that it uses the words 'if' and 'else' as opposed to ? and :

<snip>

) I have *much* less problem with this as it still very clearly an if/else
) branch. The only difference is that the variable is not referenced twice
) in the expression:
)
) if condition:
) variable = value1
) else
) variable = value2
)
) One also notes that while functionally equivilant to ?: syntax, it very
) visually demonstrates just how little value a ternary operator really
) provides over standard if/else syntax. In the end, its all just about not
) having to type a couple of variable names and newlines.

No, it's all about having a functional-programming construct.

As far as I know, all functional-programming languages have
a conditional expression operator like C's ?: operator.
It's very useful in functional programming, too.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Ben Bacarisse]

Tim Harig wrote:
) Nevertheless. Many languages do not provide this construct. Almost every
) language provides some kind of if/else construct. If it is so vitally
) important that you cannot reasonably do without it, as you guys keep
) telling me, then why isn't it such a problem in other languages that do not
) support it?

Could you name some languages that do not have this construct ?

I would say Cobol, Fortran, Pascal (and offspring like Modula-2 and -3),
PL/1 and Ada are the big ones. It's "in the works" for Ada and only a
recent arrival in Python so I suppose one could add old Python. I
*think* neither Eiffel not Lua have one.

I could be wrong about any of these -- keeping up to date in not easy.
Goodness knows what modern Cobol has in it, for example.

No point in listing those that do have such a construct; the list that
don't will be smaller though in terms of "lines of code written" may
well represent more code.

 

[Moi]

Most BCPL and by extension C derived languages do; however, Python did
not include a ternary operator until 2005 and then it is a variation of
the if/else syntax that simply allows one to assign the the value of the
if/else expression much how it is possible to assign the values of
assignments in C:

variable = if condition:
value1
else:
value2

I have *much* less problem with this as it still very clearly an if/else
branch. The only difference is that the variable is not referenced
twice in the expression:

if condition:
variable = value1
else
variable = value2

One also notes that while functionally equivalent to ?: syntax, it very
visually demonstrates just how little value a ternary operator really
provides over standard if/else syntax. In the end, its all just about
not having to type a couple of variable names and newlines.

IMHO, your thinking seems to be based solely on assignment-statements.
In C, the syntax-element is:

<lhs-expression> := <expression-a> ? <expression-b> : <expression-c>
;

The lhs-expression need not be assigned to a variable, but can still have a
useful life, eg in a switch condition (my previous example)
, or as a function argument (other example).


HTH,
AvK

 

[Phil Carmody]

On 5/22/2010 12:41, Tim Harig wrote:
[ snip ]
This isn't the tragedy that you might assume. You will note that many
languages do not support the ?: construct. They manage to get along fine
without it. We do as well.

And many do support it. I find it in the form 'iif(cond, this, that)'
in all of the xBase languages and in several SQL implementations. It
is easy to use, easy to understand and perfectly readable.

It can be found in the early 50s with LISP's (if condition val1 val2)
construct too.

Nevertheless. Many languages do not provide this construct. Almost every
language provides some kind of if/else construct. If it is so vitally
important that you cannot reasonably do without it, as you guys keep
telling me, then why isn't it such a problem in other languages that do not
support it?

Now you're putting words into our collective mouths. It, like so
much else in most languages, is not vitally important. However,
it's there and it's useful so most people are happy to use it.

Phil

 

[Ben Bacarisse]

Pascal, Ada, REXX. I suspect Fortran, COBOL, and many others.

There is probably a "long tail" of others but they are likely to be
increasingly obscure. Ada is getting one soon, BTW.

Note that some implementations of these may and that the same functionality
may be simulated using a function.

Most BCPL and by extension C derived languages do; however,

It goes by families, as you say, but most of the Algol derivatives have
one (since Algol-60 did) and all the functional languages do because it
is in their very nature.

Of course, popularity is not an obvious measure of the quality of a
construct.

Python did not
include a ternary operator until 2005 and then it is a variation of the
if/else syntax that simply allows one to assign the the value of the
if/else expression

Drifting way off topic but this is not true. Python's conditional
expression is a full-blown expression unrelated to assignment.

much how it is possible to assign the values of
assignments in C:

variable = if condition:
value1
else:
value2

I have *much* less problem with this as it still very clearly an if/else
branch.

You obviously like assignment since it seems to take the sting out of
conditional expression for you but I prefer value-based computation
wherever possible. I.e. I have few assignments and relatively complex
expressions. In C, my favoured assignments are those implicit in
function call passing (which aren't assignments in many languages).

It may be bug prone -- I have no data one way or the other. Are your
studies published anywhere? There seems to a dearth of real data about
such things.

In general I think of "if" when *doing* alternate things and ?: when
computing alternate things (much as Seebs suggested).

<snip>

 

[Tim Harig]

who? who said that? What I'm saying is that ?: is a legitimate part of
the language and I see no reason to avoid it if it does a useful job.
If we're removing the stuff that we can't do without, then there's
switch, break, continue, char, short, ++, +=, for (replace with
while).

It seems to be the general attitude among the outspoken ones.

The point is to put things into the language that appear to be useful
and expressive.Otherwise we might as well go back to machine code.

Absolutely; almost any feature is good when it is used properly and every
feature can be abused. In the end, it comes down to cost benefit analysis.
My goal is to create highly secure and reliable software. To me, anything
that is more likely to cause bugs then solve them, is an cost rather then a
benefit. If ?: really made code that much more readable, I would consider
it a valuable feature. Unfortunately, I didn't find anything that could
not be written clearly without its use and I have seen it abused. It might
not be the popular thing to do; but, I choose safety over convenience.

 

[Keith Thompson]

It seems to be the general attitude among the outspoken ones.

Please cite one example.

I think you're misunderstanding other people's opinions.
It's certainly true that some other people don't have as strong a
dislike of ?: as you do, but I don't recall seeing anyone claim or
imply that "you cannot reasonably do without it", only that it's
more convenient than the alternatives in some cases.

[...]

 

[Tim Harig]

Tim Harig wrote:
) variable = if condition:
) value1
) else:
) value2

That's almost exactly the same as:
variable = condition ?
value1
:
value2;

Except that it uses the words 'if' and 'else' as opposed to ? and :

Yep. A ternary operator is a ternary operator is a turnary operator.
Frankly, I don't know at this point whether it is superior or not as it is
new enough that I have never seen it used. If it causes the same problems
as ?: has in the past, then it will likely be banned in our coding
standards as well. If that time comes, I will support the standard.

) I have *much* less problem with this as it still very clearly an if/else
) branch. The only difference is that the variable is not referenced twice
) in the expression:
)
) if condition:
) variable = value1
) else
) variable = value2
)
) One also notes that while functionally equivilant to ?: syntax, it very
) visually demonstrates just how little value a ternary operator really
) provides over standard if/else syntax. In the end, its all just about not
) having to type a couple of variable names and newlines.

No, it's all about having a functional-programming construct.

A functional programming construct is great; but, it must be balanced
against the costs of having it abused. In the past, when we found bugs
involved using ?: during code reviews, we rewrote the code to use if/else
syntax. What we found, is that a third reviewer was more likely to spot
the bug using if/else syntax then the version using ?:.

As far as I know, all functional-programming languages have
a conditional expression operator like C's ?: operator.
It's very useful in functional programming, too.

By "functional-programming languages", are you referring to purely
functional programming languages (ie, Haskell)? I am not frankly not
knowledgable enough about the paradigm to make any decisions about code
written in purely functional programming languages. My limited
understanding is that all condtionals are basically turnary operators do
to the restriction that everything is handled as a function. That would
make it consistant across the code base rather then having two almost
indentical constructs; in which case, the problems presented here probably
do not exist.

 

[Nick Keighley]

 It might
not be the popular thing to do; but, I choose safety over convenience.

rewrite everything in Ada then

 

[bart.c]

I have *much* less problem with this as it still very clearly an if/else
branch. The only difference is that the variable is not referenced twice
in the expression:

if condition:
variable = value1
else
variable = value2

One also notes that while functionally equivilant to ?: syntax, it very
visually demonstrates just how little value a ternary operator really
provides over standard if/else syntax. In the end, its all just about not
having to type a couple of variable names and newlines.

It's about avoiding bloated code which is so spread out that you can no
longer see the big picture, just meaningless detail.

Reducing an expression to it's simplest terms has obvious benefits (did you
never do this in algebra?). Your example above can be rewritten as:

(condition|variable = value1|variable = value2)

where the common 'variable=' part can be taken outside the parentheses:

variable = (condition|value1|value2)

(and in fact you should also be able to refactor:

(condition|variable1 = value|variable2 = value)

into:

(condition|variable1|variable2) = value

except that C doesn't quite go this far.)

 

[Ben Bacarisse]

(and in fact you should also be able to refactor:

(condition|variable1 = value|variable2 = value)

into:

(condition|variable1|variable2) = value

except that C doesn't quite go this far.)

*(condition ? &variable1 : &variable2) = value;

is no so very far from what you want. The optimiser will probably be
able to do away with the * and both the &s.