Hi all,

I was looking through some code from "Eric Steven Raymond", and saw a (void) before every character output. I have never seen this before, but I'm new to programming anyway, so I googled using a 'cast before printf'. What I more or less got back, is that it's used to inform the compiler or reader that the author knowingly didn't want to use the return value; or knowingly chose not to error check it.

A simple snippet

(void) printf("To void, or not to void\n");

I also came across a comment that's it is also bad to cast malloc, but with no reference to why. I also googled that. Apparently casting malloc can create more problems than solve them: User error, returns void anyway, makes compiler accept bad implementation without creating error.

So, I would like to ask peoples opinions on these two subjects. I hope you won't mind two questions in one, they are both casts, and both a style question.

1) Should I always use a (void) cast before a functon, where I do not need to process the return value, even if the compiler will accept it without?

2) Should I stop using a cast before malloc? I seem to have read through a few books that you cast malloc to allow pointer arithmetic. After much head banging on the kitchen counter, I finally know enough about pointers not to weep. I could accept dropping the cast to malloc and move along the Bytes myself, but casting seems a simple solution that works.

Your feedback would be appreciated.

Thanks.

It's to inform the uninformed reader. The compiler never gets confused.

Some people like that style, I personally find the code much more difficult to live with if it has a lot of superfluous stuff like putting a cast on each and every printf statement.

I will go a little farther:
In addition to finding it difficult to live with, I personally find that code literally impossible to like. I hate unnecessary distractions.

However...

I personally would never take it on myself to say what a programmer should do unless I was paying him/her to create code for my use, then I might try to enforce some of my stylistic requirements as long as they didn't interfere with the creative flow.


The reason that some people prohibit casting malloc in C programs goes something like this:

You should always include <stdlib.h> in programs that use malloc, since its prototype is declared there.

If you forget to include <stdlib.h> the function might not work properly. See Footnotes.

If you don't put the cast on malloc, the compiler may give you some kind of warning.

Putting the cast on malloc suppresses the warning, thereby allowing creation of code that may misbehave.

I think that's a good reason to avoid casting malloc in C programs, and my personal style is not to put the cast. It's not wrong to put a cast there, but it is, at the very least, superfluous, and may even be a Bad Thing.

As far as using a cast on malloc to allow pointer arithmetic, I don't see what the heck casting malloc has to do with pointer arithmetic, since I wouldn't do pointer arithmetic in a statement that had malloc anyhow.

If I saw a C program where someone claimed that casting malloc was necessary for some reason, I would ask for some specific explanation.

My personal experience is that I have never written a C program where casting malloc was required, but that doesn't mean there is never a reason to do so.

Note that there is a difference between a reason and a good reason. Even if I accept that a person might have a reason for doing stuff, that doesn't mean that I automatically agree that it is a good reason.

Bottom line: I have used the word personally several times. I am expressing personal opinions. Other people have different opinions, and I respect that. I would like to see any others, not as a challenge, but as a way to learn.


Regards,

Dave

Footnote:
1.
The legacy of the earliest C compilers is that if you don't declare a function's return type and argument type before you use that function, code will be generated as though the function has an int return type and treats all of its arguments as ints. This could improper linkage with that function. I don't have any personal experience (and no desire to experiment) that shows using malloc without a prototype declaration is a Bad Thing, but why would I want to use a cast just for the heck of it? Bottom line, in my personal opinion: I generally lose the cast unless it is necessary. For example, I would never put a cast on familiar library functions like printf.

2.
If you are using malloc in a C++ program, then a cast on malloc is probably required, since, in C++, there is no inherent type conversion from pointer to void to any other kind of pointer.

However...

Why the heck would anyone use malloc in a C++ program? Use the new operator. Always.


Regards,

Dave

Hi Dave,

Thank you for the feedback. I'm only a hobbyist programmer, so I haven't got the advantage of asking better, more experienced programmers their thoughts on these kind of issues at work. Though I would like to think that if I ever release some open source programmes in the future, that I'm not making a total bodge of it. So your experienced comments are fully appreciated.

I did think the (void) before functions was a bit of overkill, but was willing to accept it, if it was the best practice. I was surprised about the malloc, because I had seen it written a few times about casting it, but the reasons not to cast seem valid enough not to use it.

Your comment about pointer arithmetic implies I don't yet fully understand this area, which may be true, so I will go back to the books on this part. I could tell you my understanding of pointer arithmetic, but that may be a change of thread matter, and may show more of my ignorance or grasp on that matter. A bit more googling and reading may be the right way to go for me on that matter.

I have found this forum a good place to learn parts of C that just doesn't appear in books. I have also spent most of my time reading old threads from past questions about problems. One thing I appreciate about this kind of site, and this one especially, is that a sole non-professional can get help from more connected and experienced programmers.

Thanks Dave,

Martin.

Martin: Your questions brought up some good points and covered a couple of things that lots of people don't understand. I mean, they may have read someone else's opinion on what to do, but didn't see any explanation as to why. Sometimes, even if it seems to be a matter of personal taste, the actual style is important. The definition of "best practices" is sometimes a matter of opinion, and not all (so-called) experts always agree.

Please don't hesitate to ask questions here. There are lots of people who will try to help.
Me too. I always learn something when I visit this site. Always.

Regards,

Dave

Re a cast on malloc . Use calloc , and that does need a cast unless you want void memory.

The issue of whether to put a cast on calloc when it is used in a program is exactly the same as for malloc. In fact, the issue is the same for all functions that your program calls.

If you include <stdlib.h>, calloc and malloc don't need a cast in C programs. It's not "wrong" to put a cast, and nothing "bad" will happen, but consider the following:

If you don't include <stdlib.h> and you don't put a cast on malloc or calloc, there may be problems linking all of your program's functions together into an executable (or, maybe, not). The compiler may give a warning which is significant (or, maybe, not). If your compiler goes to the trouble to issue such a warning, this serves to remind you that you forgot to include <stdlib.h>

If you don't include <stdlib.h> and you put a cast on malloc or calloc, the warning that your friendly, helpful compiler might have given you is suppressed at compile time, and if there are problems, they won't manifest themselves until execution time, and you won't have a clue as to what the problem really is.

In summary:

1. You should include <stdlib.h> if you are going to use malloc or calloc.

2. If you really, really (really) want to cast malloc or calloc, well, it's not "wrong," but there is no advantage to doing so. Really.

Bottom line: If doing something (like putting a cast on malloc or calloc) can not possibly make things better but it just might make them worse, then why (oh, why) would you do that?



The same is true of all functions:

As a general practice you should always declare any functions before you call them in a program. If the function implementation (the actual body of the function) appears in a file before the function is called, that's OK. If the body of the function appears later on in the file (after the function is used), the prototype of the function should be declared before the function is called. You can put the prototype earlier in the same file or you can put it in a header file that is included.

For a standard library function, the appropriate way to declare the function is to include the standard library header that contains that function's prototype.

Regards,

Dave

Thanks for that kind and immediate response.
My principle references are the help pages in Borland Turbo C and C Programming guide by Jack Purdum. Both instruct that a cast should be used.
I will experiment with all the compilers I have to see what happens. I will report back in one or two days.

Although my comment may have been interpreted by some as a flat statement that, emphatically, nothing good will happen if you put a cast on malloc, it was actually an opinion, rooted in the context of compilers newer than 1989 (or at least that made some effort at compliance with standard language specifications). See Footnote.

In some old compilers there was no such thing as "pointer to void" and malloc was declared to have a "pointer to char" return type. In that case something like the following would give a warning that the program was converting to a potentially incompatible data type:


The way to suppress that warning was with


In addition to my general aversion to superfluous typing in programs, I gave another reason that I use the first style and don't use (and don't like) the second style.


If other people have their reasons for doing this, whether they are blindly following twenty-year old usage that might have been desirable with some now-obsolete compiler that predated language standards or for whatever other reason, well, I say, "Chacun à son goût!"


Regards,

Dave

Footnote: Someone mentioned that a reason to put the cast is that sometimes we want to take our C source code and make it part of a C++ program. In C++, there is no implicit type casting of pointer to void to make it some other kind of pointer, so the cast would be required. Not a matter of style or taste. Required.

I personally don't accept this as a good reason to clutter up my C code with superfluous casts, since there are a few other incompatibilities between C and C++, and I am personally loathe to accept any C code to be compiled as C++ without looking at it and making necessary changes. I'm funny that way.


Now I'm really finished with this subject.

Dave
"Over and out."

I write for the widest compatibility.

Here is my test.c

I tested this in Borland Turbo C and their Win45, plus DMC and GCC.
Win45 rejected long long, so the offenders were deleted and it warned of unuse. But Turbo C accepted everything, compiling long long as long.
No other compilation warnings or errors were produced, and all programs ran as they should.
So I have to apologise for my post about calloc above.
Many thanks.