Good advice, although I also insist on -Werror, I.e. turn all warnings into errors. This makes you fix warnings immediately. That sounds annoying, but warnings are like emails: they tend to pile up, and by the time the pile reaches a certain size you give up on it and just ignore it. At that point, warnings are useless. Actually they become useless earlier, when there are enough that it isn’t easy to detect a new one appearing.
If you use Xcode, you can download a configuration file XcodeWarnings.xcconfig that enables (nearly) every possible warning. The idea is you set it as the base config file for your project, then comment out any of the warnings that get in your way. I’ve been using it for years; it’s great.
It’s generally a good idea to enable -Werror in CI me for local development, but not in the default build. If someone downloads your code, it’s annoying for them to discover that they need to futz with build flags because they are using a compiler that you didn’t test with that has a warning (that may or may not be a false positive).
Doing Rust stuff I occasionally take a slightly more lax approach that still forces me to fix warnings: I have a pre-commit hook that disallows commits when there are any warnings. It lets me hack on things without interruption, but then forces me to go back and clean up a little before pushing.
Huh, thought of that and went “but that’s slower”. But if you’re doing incremental commits and pushing to a branch, and only want to merge that branch when it’s clean, then that’s not a bad choice either.
The issue I have with this is the following warning from GCC:
gcc -std=c99 -g -Wall -Wextra -pedantic -fPIC -shared -L/usr/local/lib -o lib/tcc.so src/tcc.c -ltcc
src/tcc.c: In function `tcclua_get_symbol':
src/tcc.c:528: warning: ISO C forbids assignment between function pointer and `void *'
While ISO C might disallow that, POSIX requires it, and I haven’t found a way around this one warning.
You can cast via uintptr_t to avoid warnings about forbidden pointer casts. This works for object/function conversions, and for casting away const. Use this forbidden knowledge wisely, lest you receive a visitation from the nasal demons!
gcc is doing what you tell it to: compiling to the c99 standard and being pedantic about it.
In C99, you cannot cast a function pointer to any object pointer (portably). There are architectures where the text and code regions have different address sizes, and the main appeal of the C language is that it’s portable to a massive number of architectures.
So you need to decide what you want: Do you want to write fully-portable C99, or do you want to use GCC language extensions?
Both answers are completely reasonable, and function pointer casts in particular are supported on many different C implementations. If you choose to go this route, you can change std=c99 to std=gnu99 and your problem will disappear.
The full log should include the specific flag that produced that warning; you then invert it (change -Wfoobar to -Wno-foobar) and add that to the warning flags.
Okay, I tried on a later version of GCC. This is what I got:
src/tcc.c: In function ‘tcclua_get_symbol’:
src/tcc.c:528:10: warning: ISO C forbids assignment between function pointer and ‘void *’ [-Wpedantic]
528 | call = tcc_get_symbol(*tcc,luaL_checkstring(L,i));
I’m hesitant to remove -pedantic just to remove this one warning.
I wish people would include -Wpedantic in their set of useful warning flags. I often see unintentional use of non-standard C extensions that could have been easily avoided just because they didn’t know it wasn’t standard and the compiler didn’t tell them by default.
Good advice, although I also insist on -Werror, I.e. turn all warnings into errors. This makes you fix warnings immediately. That sounds annoying, but warnings are like emails: they tend to pile up, and by the time the pile reaches a certain size you give up on it and just ignore it. At that point, warnings are useless. Actually they become useless earlier, when there are enough that it isn’t easy to detect a new one appearing.
If you use Xcode, you can download a configuration file XcodeWarnings.xcconfig that enables (nearly) every possible warning. The idea is you set it as the base config file for your project, then comment out any of the warnings that get in your way. I’ve been using it for years; it’s great.
It’s generally a good idea to enable -Werror in CI me for local development, but not in the default build. If someone downloads your code, it’s annoying for them to discover that they need to futz with build flags because they are using a compiler that you didn’t test with that has a warning (that may or may not be a false positive).
Doing Rust stuff I occasionally take a slightly more lax approach that still forces me to fix warnings: I have a pre-commit hook that disallows commits when there are any warnings. It lets me hack on things without interruption, but then forces me to go back and clean up a little before pushing.
Alternatively, deny warnings on CI:
https://github.com/matklad/once_cell/blob/35148638c54c6233545c65d1a5e09d5ba0661806/.github/workflows/ci.yaml#L12
Huh, thought of that and went “but that’s slower”. But if you’re doing incremental commits and pushing to a branch, and only want to merge that branch when it’s clean, then that’s not a bad choice either.
The issue I have with this is the following warning from GCC:
While ISO C might disallow that, POSIX requires it, and I haven’t found a way around this one warning.
You can cast via
uintptr_tto avoid warnings about forbidden pointer casts. This works for object/function conversions, and for casting awayconst. Use this forbidden knowledge wisely, lest you receive a visitation from the nasal demons!gccis doing what you tell it to: compiling to the c99 standard and being pedantic about it.In C99, you cannot cast a function pointer to any object pointer (portably). There are architectures where the text and code regions have different address sizes, and the main appeal of the C language is that it’s portable to a massive number of architectures.
So you need to decide what you want: Do you want to write fully-portable C99, or do you want to use GCC language extensions?
Both answers are completely reasonable, and function pointer casts in particular are supported on many different C implementations. If you choose to go this route, you can change
std=c99tostd=gnu99and your problem will disappear.This one requires fixing the API. This is why dlfunc exists in FreeBSD libc, for example.
The full log should include the specific flag that produced that warning; you then invert it (change -Wfoobar to -Wno-foobar) and add that to the warning flags.
Okay, I tried on a later version of GCC. This is what I got:
I’m hesitant to remove
-pedanticjust to remove this one warning.I wish people would include
-Wpedanticin their set of useful warning flags. I often see unintentional use of non-standard C extensions that could have been easily avoided just because they didn’t know it wasn’t standard and the compiler didn’t tell them by default.