When to check the return value of malloc

B

bart.c

(Explanation of (a|b|c) vs. a?b:c got edited out)
*(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.

That works fine (it's exactly what I use internally to implement my
example). Makes you wonder what the fuss over just having a?b:c directly as
an lvalue is all about. After all we aren't obliged to write *(&a)=b.
 
K

Keith Thompson

bart.c said:
(Explanation of (a|b|c) vs. a?b:c got edited out)


That works fine (it's exactly what I use internally to implement my
example). Makes you wonder what the fuss over just having a?b:c directly as
an lvalue is all about. After all we aren't obliged to write *(&a)=b.

I'm not convinced there's much of a "fuss" about it. You just can't do
it.

Note that

(condition ? variable1 : variable2) = value;

can't be exactly equivalent to

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

in all cases. For one thing, variable1 and/or variable2 might not
have an address (it might be a bit field or register variable).
For another, you've have to establish rules about the relationship
between the types of the second and third operands, rules that
would have to be stricter than those for a non-lvalue conditional
expression. Which probably means that this:

int variable1;
double variable2;
if (condition) {
variable1 = 42;
}
else {
variable2 = 42;
}

couldn't be modified to use a lvalue conditional expression --
or if it could, the rules and semantics might get very complicated.

On the other hand, I think C++ does allow this, so apparently the
problems are solvable.
 
P

Phil Carmody

Tim Harig said:
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,

you should have realised you were employing insufficiently skilled
programmers.
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 ?:.

You are also employing insufficiently skilled reviewers.

Phil
 
B

Ben Bacarisse

Keith Thompson said:
I'm not convinced there's much of a "fuss" about it. You just can't do
it.

Note that

(condition ? variable1 : variable2) = value;

can't be exactly equivalent to

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

in all cases. For one thing, variable1 and/or variable2 might not
have an address (it might be a bit field or register variable).
For another, you've have to establish rules about the relationship
between the types of the second and third operands, rules that
would have to be stricter than those for a non-lvalue conditional
expression.
On the other hand, I think C++ does allow this, so apparently the
problems are solvable.

The C++ standard's description of ?: is very much longer than that in
the C standard, but that seems to be mainly due to class types and the
fact that C++ does have C's simple rules for arithmetic conversions.
The only part that relates to the case in question is paragraph 4:

4 If the second and third operands are lvalues and have the same type,
the result is of that type and is an lvalue.

That's a simple rule that would work in C as well as in C++. It rules
out some cases that might otherwise be allowed by a more complex rule
but I think it would fit well into C.
 
B

bart.c

Keith Thompson said:
I'm not convinced there's much of a "fuss" about it. You just can't do
it.

Note that

(condition ? variable1 : variable2) = value;

can't be exactly equivalent to

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

in all cases. For one thing, variable1 and/or variable2 might not
have an address (it might be a bit field or register variable).

That would be an advantage of having the construct properly built in.
For another, you've have to establish rules about the relationship
between the types of the second and third operands, rules that
would have to be stricter than those for a non-lvalue conditional
expression.

Written using * and &, the two possible results of ?: would need to be
pointers to the same type.
Which probably means that this:

int variable1;
double variable2;
if (condition) {
variable1 = 42;
}
else {
variable2 = 42;
}

couldn't be modified to use a lvalue conditional expression --
or if it could, the rules and semantics might get very complicated.

That's true; an if/else /statement/ can contain completely independent
assignments (and for that matter, anything else).

However I was specifically interested in cases where if/else could be
profitably written as an ?: expression.
On the other hand, I think C++ does allow this, so apparently the
problems are solvable.

The ?: construct can be nested, giving a potentially unlimited number of
conditional lvalues to sort out (even ignoring any other unrelated, embedded
lvalues in the lhs expression).

Allowing mixed lhs lvalue types would be tricky (I'm implementing something
similar: I require all the lvalues to be of the same type if the assignment
is to be done efficiently).
 
T

Tim Rentsch

Keith Thompson said:
sandeep said:
Yes, of course!


This is very bad practise. Localizing the #define is good for the same
reason that using local instead of global variables.

So use a local variable.

I don't think I've ever seen C code in which a macro is #define'd, then
used, then immediately #undef'ed. I can see the argument in favor of
doing it, but in practice most macros are global anyway.

But again, there's no good reason to use a macro rather than a
constant object declaration:

const size_t esize = 0x40000000;

If you want it scoped locally, use a feature that lets the compiler
handle it for you.

Even your #define/#undef pair doesn't do the same thing as a local
declaration; it clobbers any previous definition.

[...]
I think this is wrong. With no "qualifier", the number will be
interpreted as an int and undergo default promotions. Because int may be
16 bits this could overflow.

Nope. An unqualified integer constant, unless it exceeds UINTMAX_MAX (I
think that's the right name) is always of some type into which its value
will fit. [snip unrelated following]

Not quite. An unqualified decimal integer constant must not
exceed INTMAX_MAX. It is only octal or hexadecimal integer
constants that may go up to UINTMAX_MAX.
 
T

Tim Rentsch

Phil Carmody said:
Joe Wright said:
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.

The late 1950's; more specifically 1958, IIANM.

It's worth remembering that the conditional expression in
LISP predates 'if/then/else' in Algol and all the languages
that followed it. Supposedly 'if/then/else' was put into
Algol because of the conditional expressions (namely, 'cond')
present in LISP. So an argument that 'if/else' is more
fundamental appears to be revisionist history.
 
K

Keith Thompson

Tim Rentsch said:
Nope. An unqualified integer constant, unless it exceeds UINTMAX_MAX (I
think that's the right name) is always of some type into which its value
will fit. [snip unrelated following]

Not quite. An unqualified decimal integer constant must not
exceed INTMAX_MAX. It is only octal or hexadecimal integer
constants that may go up to UINTMAX_MAX.

You're right.

(Note that in C90, an unsuffixed decimal integer constant could be of
type int, long, or unsigned long; in C99 it can only be of a signed
type, possibly an extended type if the implementation supports them.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top