about gcc 4.2

P

parag_paul

The following conflict is of importance to my work here. with porting
happening in gcc4.2 from gcc3.4 we have to
do the following
# (void *)printf() should be (void)printf()

Can anybody explain the rational behind the same.
-Parag
 
R

Richard Heathfield

(e-mail address removed) said:
The following conflict is of importance to my work here. with porting
happening in gcc4.2 from gcc3.4 we have to
do the following
# (void *)printf() should be (void)printf()

Remove the cast in both cases. This is nothing to do with gcc (which is
just as well, as it would have been off-topic otherwise), and everything
to do with people adding stupid pointless casts that damage the
readability of the code.
Can anybody explain the rational behind the same.

There isn't one. Just rip the casts out. They're ridiculous.
 
P

parag_paul

but what could have been the point in adding the casts.
Do you think the user might have had a good reason for it.
Sorry if the discussion is hitting the wall on this!
-Parag
 
J

James Kuyper Jr.

The following conflict is of importance to my work here. with porting
happening in gcc4.2 from gcc3.4 we have to
do the following
# (void *)printf() should be (void)printf()

Can anybody explain the rational behind the same.

The (void*) cast serves no useful purpose. On the other hand, the (void)
cast disables the warning message that some compilers and code checkers
generate which complains about the fact that you're not using the return
value from the function. I prefer to disable that feature of the
compiler, instead. If it can't be turned off, I'd use a different
compiler. However, sometimes that's not a feasible option.
 
J

jaysome

(e-mail address removed) said:


Shutting up a bad lint.

And it should be noted that the good lints allow you to suppress this
warning on a per-function basis, using a configuration file setting,
without having to modify your source code. For example:

-esym(534,memset, strcat, strcpy, fprintf, sprintf, memcpy, printf,
fgets, sscanf, fflush, vsprintf)

Caution should be exercised to only use Standard C functions in such a
setting.

Best regards
 
C

Charlie Gordon

jaysome said:
And it should be noted that the good lints allow you to suppress this
warning on a per-function basis, using a configuration file setting,
without having to modify your source code. For example:

-esym(534,memset, strcat, strcpy, fprintf, sprintf, memcpy, printf,
fgets, sscanf, fflush, vsprintf)

While I agree that the return values of most of these functions can be
safely ignored,
- sprintf should be deprecated in favor of snprintf,
- sscanf (and other scanf) return value should *not* be ignored.
Caution should be exercised to only use Standard C functions in such a
setting.

What is wrong with adding locally functions defined for which the warning is
not useful ?
This configuration file should be customized on a project basis.
 

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
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top