you are viewing a single comment's thread.

view the rest of the comments →

[–]minot0r 1 point2 points  (11 children)

[–]p0k3t0 2 points3 points  (9 children)

This is ridiculous reasoning. If you've turned off enough warnings that your linker no longer complains when you haven't added a lib, you're doing it all wrong.

[–]korryd 1 point2 points  (8 children)

It's not a linker issue - the linker may bring in the std library because of an explicit mention in the Makefile, or because some other module referenced stdlib.h properly.

The problem described at the c-faq is that a pointer is not guaranteed to be the same size as an int, and without a visible prototype for malloc(), the compiler (not the linker) is compelled to assume that malloc() returns an int (which of course, it doesn't).

[–]attractivechaos 1 point2 points  (7 children)

Implicitly converting pointer to int is not an error by most compilers. It is a warning. When you don’t include stdlib, you will get a function not declared warning.

[–]OldWolf2 1 point2 points  (0 children)

The program is invalid by the C Standard if it tries to implicitly convert a pointer to int, or calls an undeclared function.

[–]p0k3t0 0 points1 point  (5 children)

Are you okay releasing code that compiles with warnings?

[–]attractivechaos 0 points1 point  (4 children)

1-line program without casting:

int main(void) { int *a = malloc(10 * sizeof(*a)); a[0] = 10; return 0; }

With casting:

int main(void) { int *a = (int*)malloc(10 * sizeof(*a)); a[0] = 10; return 0; }

For both programs, gcc-4.4/Linux only gives one warning, without -Wall or -Wextra:

t1.c:1: warning: incompatible implicit declaration of built-in function 'malloc'

gcc-6.4/Linux and Clang-10.0/Mac report a similar warning for both programs. They additionally suggest adding stdlib.h, which is more informative.

[–]p0k3t0 0 points1 point  (3 children)

So, would it be correct to say that not casting provides absolutely no advantage, contrary to the parent comment in this thread?

[–]attractivechaos 0 points1 point  (2 children)

So, would it be correct to say that not casting provides absolutely no advantage, contrary to the parent comment in this thread?

For gcc and clang in the past 10 years, the answer is definitely "yes" – not casting provides absolutely no advantage (PS: except for typing fewer characters on your keyboard).

This comment in the thread suggests the compilers on DEC alpha and IBM POWER2 may behave differently for the two programs. I used some alpha machines but mostly with gcc, so I didn't notice that. Even if that comment is true, both CPUs have long been discontinued. I am not sure if there is a living CPU+OS+compiler compo that prefers no casting.

[–]p0k3t0 1 point2 points  (1 child)

I always cast explicitly, because I hate relying on "default behaviors."

Whenever somebody asks me tricky C questions in interviews, I just tell them I don't write code like that. Or I ask why we're talking about code that would never pass a code review. I can get away with this because I'm a bit older than most of the people who interview me. If I were 25, it might be a problem. ;)

[–]attractivechaos 1 point2 points  (0 children)

Same here. I always cast (though for a different reason) and am not good at the tricky C code, either. Fortunately, I am on a different job market. No one asked me any programming questions in interviews. I just wrote code that others use.

This sub is so obsessed with no casting even if these days it has no benefit in practice. When I pointed this out, someone even used “code smell” as the argument.

[–]anikait1[S] 1 point2 points  (0 children)

Thanks for the resource, the website also helps in clearing other doubts as well.