Effin' malloc()

[stuka]

Ok, here's the code...it's segfaulting (on me) in the server.c file.

[sedarious]

you know what function you are getting the seg-fault in?

[stuka]

sedarious: yeah, did a backtrace on it last night - it's segfaulting in the malloc() call - I posted this 'cuz Strike was helpin' me in IRC late last night/early this morning. (Note the title of the thread too ;) ). The failure is in the return_data() method in server.c. I repeat: effin' malloc!

[jamessan]

Shouldn't the malloc call be:
char* fifi_name = (char*)malloc(6 + strlen(FIFO_PREFIX)*sizeof(char));

[kmj]

sizeof char is 1 byte (unless you're using unicode), so it probably doesn't matter. Now if he were using int's float's or other such things, it might make a difference.

[jamessan]

Oh yeah. Yay for just having woken up.

[stuka]

Well, it appears that this is only an issue with the libc that ships with Slack 8 - it worked fine on Strike's box (deb, I'm sure) and on our Solaris machines @ school.

[Strike]

Originally posted by Stuka
Well, it appears that this is only an issue with the libc that ships with Slack 8 - it worked fine on Strike's box (deb, I'm sure) and on our Solaris machines @ school.
Yeah, GNU libc6 2.3.1

[sedarious]

Originally posted by Stuka
sedarious: yeah, did a backtrace on it last night - it's segfaulting in the malloc() call - I posted this 'cuz Strike was helpin' me in IRC late last night/early this morning. (Note the title of the thread too ;) ). The failure is in the return_data() method in server.c. I repeat: effin' malloc!

Yeah, it was the retun_data() part that I was looking for. I wasn't sure if it was dropping IN malloc or because of something malloc did from the original post.

[kmj]

Damnit stuka.. I blame you! I'm getting segfaults inside malloc, myself now... In debian and mandrake..

[stuka]

no joke? with my code, or something else? and what version of libc?

[kmj]

No, with my code.. dunno what libc6, I'd have to ssh in.

[stuka]

wow...so I'm NOT the only one!

[kmj]

I ran it on a school computer, and it segfaults in a different place. That may be due to shoddy code, though. I'm not sure yet.

[stuka]

ah..ok

[kmj]

turns out it was our fault. We're doing recursion and using a global table of strings, and passing alot of shit around. There was alot of room for error. :) I still am not sure how a segfault can occur inside a call to malloc with a request for a a reasonable chunk of bytes. Needless to say, we were seriously effing our heap up.

[stuka]

Well, that makes me feel a little better - one libc bug, isolated fairly small, is easy to believe in.

[DrPizza]

Originally posted by jamessan
Shouldn't the malloc call be:
char* fifi_name = (char*)malloc(6 + strlen(FIFO_PREFIX)*sizeof(char));
No.

One should not cast the return value of malloc() when writing C.

When stdlib.h has been included, malloc()'s declaration will be visible. Its return type is void*, and void* can be silently converted to other pointer types.

If one should forget to include the declaration, malloc will be assumed to return int.

ints will be converted to pointer types -- but typically that conversion will not be silent. Most, if not all, C compilers will produce a warning to the effect of "you are converting an int into a pointer without explicitly casting -- are you sure you want to?". This alrerts one to the fact that one has omitted to include a header.

If you put the cast in, that message will be quashed -- after all, the point of casts is to say to the compiler, "Ignore what you think you know and do what I say" -- and a [potential] problem be left latent in your code.

In C++ the rules are different; C++ has no implicit declarations of functions (they must be seen to be used) so the latter problem will always be diagnosed, and C++ has no implicit conversions from void*, so the conversion will be required. But, of course, in C++ one should be using new instead.

Furthermore, sizeof(char) is 1 by definition, so is useless. But in general, it is probably better to not write sizeof(type) but rather, sizeof(expression). Something like sizeof(*FIFO_PREFIX). In this way, the type that sizeof is working on is always the right size for the array.

[stuka]

Originally posted by DrPizza

One should not cast the return value of malloc() when writing C.

When stdlib.h has been included, malloc()'s declaration will be visible. Its return type is void*, and void* can be silently converted to other pointer types.

ints will be converted to pointer types -- but typically that conversion will not be silent. Most, if not all, C compilers will produce a warning to the effect of "you are converting an int into a pointer without explicitly casting -- are you sure you want to?". This alrerts one to the fact that one has omitted to include a header.

If you put the cast in, that message will be quashed -- after all, the point of casts is to say to the compiler, "Ignore what you think you know and do what I say" -- and a [potential] problem be left latent in your code.


Wow - the most coherent (and best to date) explanation I've seen on this whole issue. You caught me on one thing - I learned C++ first, so it shows (I always cast the malloc() return). Thanks for the logic behind not casting it - makes a ton of sense!

[bwkaz]

Originally posted by DrPizza
Furthermore, sizeof(char) is 1 by definition, so is useless. But in general, it is probably better to not write sizeof(type) but rather, sizeof(expression). Something like sizeof(*FIFO_PREFIX). In this way, the type that sizeof is working on is always the right size for the array.

Even on Unicode or UTF-8 machines? What about EBCDIC? (I know, I know, EBCDIC sucks, but that's not the point, not here at least ;) )

I believe (though I could be wrong...) that a char is only 8 bits on ASCII machines -- other larger character sets require more bits to hold their larger symbol set, so they require larger characters. Which is where wchar_t comes in.

Actually, I may have just answered my own question, at least in the case of UTF-8 or Unicode machines. You don't use char, you use wchar_t. I'm still not sure about EBCDIC though.

[skidooer]

Originally posted by bwkaz
Even on Unicode or UTF-8 machines? What about EBCDIC? (I know, I know, EBCDIC sucks, but that's not the point, not here at least ;) )
char is always 1, but a byte does have to be 8 bits.

[DrPizza]

Originally posted by bwkaz
Even on Unicode or UTF-8 machines? What about EBCDIC? (I know, I know, EBCDIC sucks, but that's not the point, not here at least ;) )
Even on those.

By definition sizeof(char) is 1, and sizeof gives the size in chars.

I believe (though I could be wrong...) that a char is only 8 bits on ASCII machines -- other larger character sets require more bits to hold their larger symbol set, so they require larger characters. Which is where wchar_t comes in.
Well that's rather the point of wchar_t -- char's already got a relatively fixed size, so you need wchar_t for things larger than char.

[kmj]

By definition sizeof(char) is 1, and sizeof gives the size in chars.


Out of curiousity, by definition where? Whose definition are we talking about? ANSI?

[bwkaz]

If sizeof gives size in chars, then of course sizeof(char) will be one. But what if a char is actually larger than one byte? I guess I'm not sure any more that that could ever happen, but what if? Doesn't malloc take a number of bytes to allocate, not a number of chars?

[DrPizza]

Originally posted by kmj
Out of curiousity, by definition where? Whose definition are we talking about? ANSI?
ANSI hence ISO.

================

If sizeof gives size in chars, then of course sizeof(char) will be one. But what if a char is actually larger than one byte?
It's not possible. A byte is the size required to hold a character of the native character set (reference (http://www.tuxedo.org/~esr/jargon/html/entry/byte.html)). That's also how a char is defined.

I guess I'm not sure any more that that could ever happen, but what if? Doesn't malloc take a number of bytes to allocate, not a number of chars?
The point is that they are the same.

[bwkaz]

Hm. OK then.