simple malloc() problem

[Keith Thompson]

I can see no attack, merely an accurate statement of fact.

No, Dan, it's your opinion.

 

[Dan Pop]

No, Dan, it's your opinion.

Based on facts accumulated over a period of several years. Easily
verifiable with Google, if you have nothing better to do...

Dan

 

[Dan Pop]

If I was working for Dan and he wanted to modify input parameters, so be
it.

All I want from a programmer is to do whatever makes most sense under the
specific circumstances, rather than using a system of *inflexible* rules.

Come to think of it, my own inflexible rules are:

1. Identifiers must make as much sense as possible in as few characters
as possible.

2. Code must be indented (the style doesn't matter).

3. Dereferencing a function pointer must not look like an ordinary
function call.

4. Macros should be spelled in upper case (with the possible exception
of those having the same semantics as a function call).

5. typedef is not a typing saving device.

6. Reserve implicit comparisons against 0 for conceptual booleans.

7. If a function can fail, don't ignore checking its success, unless there
is a good reason for that.

8. Don't use any declaration more complex than the declaration of a
pointer to function or pointer to array. For anything more complex
than that, use typedefs.

With one exception (related to correctness) all of them are related to
writing readable C code (or what I consider readable C code).

Maintainable C code is, for me, at least, a matter of code design rather
than than code writing.

Dan

 

[Rufus V. Smith]

In <[email protected]>

All I want from a programmer is to do whatever makes most sense under the
specific circumstances, rather than using a system of *inflexible* rules.

Come to think of it, my own inflexible rules are:

1. Identifiers must make as much sense as possible in as few characters
as possible.

2. Code must be indented (the style doesn't matter).

3. Dereferencing a function pointer must not look like an ordinary
function call.

4. Macros should be spelled in upper case (with the possible exception
of those having the same semantics as a function call).

5. typedef is not a typing saving device.

6. Reserve implicit comparisons against 0 for conceptual booleans.

7. If a function can fail, don't ignore checking its success, unless there
is a good reason for that.

8. Don't use any declaration more complex than the declaration of a
pointer to function or pointer to array. For anything more complex
than that, use typedefs.

Thank you, thank you, thank you.

I get so annoyed at those who fall back on:
"Anyone who knows C should be able to read this."

Although wrt #5 in the list. I have been guilty of using #define as a
typing
saving device. Of course, I justify by saying "it ensures consistent
usage".

Rufus

 

[Default User]

2. Code must be indented (the style doesn't matter).

I'd add that the indentation style should be internally consistent.



Brian Rodenborn

 

[tweak]

Your problem is covered by the FAQ:

http://www.eskimo.com/~scs/C-faq/q4.8.html

I went to the faq and it looks like:

void f(ip)
int *fp;
{
static int dummy = 5;
ip = &dummy;
}

shouldn't the above read:

int *fp;

void f(ip) {

static int dummy = 5;
ip = &dummy;
}

If so, could you correct it?

Brian

P.S. The FAQ really does answer the question even
though the poster thought their problem
was malloc(), which had the wrong size_t --
cutting off '\0'.

Note: The only item I can find regarding casting
of malloc() is K&R2 pg. 142:

"In C, the proper method is to declare that
malloc return a pointer to void, then
explicitly coerce the pointer into the
desired type with cast."

Now, I couldn't find anything specific in
ISO C99, so I guess it's up to the programmer
to decide.

 

[Keith Thompson]

I went to the faq and it looks like:

void f(ip)
int *fp;
{
static int dummy = 5;
ip = &dummy;
}

Not quite. It actually looks like this:

void f(ip)
int *ip;
{
static int dummy = 5;
ip = &dummy;
}

There is no "fp".

The code fragment uses an old-style function declaration, which is
a bit odd. I'd prefer this:

void f(int *ip)
{
static int dummy = 5;
ip = &dummy;
}

shouldn't the above read:

int *fp;

void f(ip) {

static int dummy = 5;
ip = &dummy;
}

Um, no.

 

[tweak]

Not quite. It actually looks like this:

void f(ip)
int *ip;
{
static int dummy = 5;
ip = &dummy;
}

There is no "fp".

The code fragment uses an old-style function declaration, which is
a bit odd. I'd prefer this:

void f(int *ip)
{
static int dummy = 5;
ip = &dummy;
}




Um, no.

Thanks for correcting me. I've never seen the style before.

Yeah. It should be fp(int *ip).

Thanks,

Brian

 

[Irrwahn Grausewitz]

I went to the faq and it looks like:

void f(ip)
int *fp;
{

[...]
Not quite. It actually looks like this:

void f(ip)
int *ip;
{ [...]
The code fragment uses an old-style function declaration, which is
a bit odd.

This is due to the fact that the HTML rendition of the FAQ is *not*
the most recent version. In the up-to-date text version the old-style
declaration is sensibly replaced by:

void f(int *ip)
{
[...]

I suggest to always use the text version of the FAQ.

Regards

 

[Darrell Grainger]

I went to the faq and it looks like:

void f(ip)
int *fp;
{
static int dummy = 5;
ip = &dummy;
}

Actually, it is:

void f(ip)
int *ip
{
static int dummy = 5;
ip = &dummy;
}

This is the old way of declaring a function. You list all the parameters
without their type in the () area. Then on lines between the first line
and the { you place the parameter types. The main function would be
written as:

int main(argc, argv)
int argc;
char **argv;
{
/* your code here */
return 0;
}

It is good to know this format for those times you need to maintain some
old code but you should not use this format anymore.

P.S. The FAQ really does answer the question even
though the poster thought their problem
was malloc(), which had the wrong size_t --
cutting off '\0'.

This would have been covered by:

http://www.eskimo.com/~scs/C-faq/q7.19.html

Note: The only item I can find regarding casting
of malloc() is K&R2 pg. 142:

"In C, the proper method is to declare that
malloc return a pointer to void, then
explicitly coerce the pointer into the
desired type with cast."

Now, I couldn't find anything specific in
ISO C99, so I guess it's up to the programmer
to decide.

The FAQ http://www.eskimo.com/~scs/C-faq/q7.6.html talks about the correct
thing to do but it does not explain why casting the result of malloc is a
bad thing. Also http://www.eskimo.com/~scs/C-faq/q7.7.html talks about the
history of why code had previously cast the result of malloc but again, it
does not talk about why it is now a bad thing.

I guess "Why is casting the result of malloc a bad thing?" would make for
a good FAQ.

 

[Tim Hagan]

I guess "Why is casting the result of malloc a bad thing?" would make for
a good FAQ.

This FAQ has been beaten to death in clc. Ben Pfaff has provided a VGA
(Very Good Answer) at http://benpfaff.org/writings/clc/malloc-cast.html.

 

[tweak]

tweak wrote:




Check the errata:
http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html

142(§6.5, toward the end): The remark about casting the return value
of malloc ("the proper method is to declare ... then
explicitly coerce") needs to be rewritten. The example is correct
and works, but the advice is debatable in the context of the
1988-1989 ANSI/ISO standards. It's not necessary
(given that coercion of void * to ALMOSTANYTYPE * is automatic),
and possibly harmful if malloc, or a proxy for it,
fails to be declared as returning void *.
The explicit cast can cover up an unintended error.
On the other hand, pre-ANSI, the cast was necessary,
and it is in C++ also.

Thanks.

I didn't know there was a errata from the book available since
it's pretty old.

Thanks Again,

Brian

P.S. Sorry about messing up my understanding of the syntax.

 

[Darrell Grainger]

This FAQ has been beaten to death in clc. Ben Pfaff has provided a VGA
(Very Good Answer) at http://benpfaff.org/writings/clc/malloc-cast.html.

I'm suggesting that it should be added to the comp.lang.c official FAQ.