I'm trying to move from msvc to clang and I'm having trouble finding info on some of the flags I'm using. Also, I know there is clang-cl but I'm trying to use zig cc as my compiler and it only excepts normal clang flags as far as I know.
In msvc I use -Eha- since I don't use exceptions and don't want compiler to generate any exception handling code. Is there an equivalent flag on clang? Or is this disabled by default? Also, I'm not linking to the CRT and in order to do this with MSVC I'm disabling security checks with -GS- and stack probing with -Gs9999999 (according to this guide https://hero.handmade.network/forums/code-discussion/t/94-guide_-_how_to_avoid_c_c++_runtime_on_windows). Is there an equivalent with clang? I searched for some keywords in clangs compiler flag documentation but having trouble finding info
Edit:
Was given a suggestion to try to add the option 'clang:-fno_exceptions' to clang-cl but got the warning: "clang-cl: warning: fno-exceptions: 'linker' input unused [-Wunused-command-line-argument]". Tried adding it as an argument to lld-link but get unknown argument.
Here is the argument list I'm passing with clang-cl
REM -GS- tells compiler to not worry about security calls (like __security_cookie) that would typically be inserted with c libs. -Gs99999999999 basically says don't worry about __chkdsk for checking stack overruns
set compiler_flags=-clang:-g -clang:-fdebug-macro -clang:-O0 -clang:-fno-exceptions -GS- -clang:-mstack-probe-size=9999999 -wd4505 -wd4101 -wd4530 -w14700 -wd4100 -we4820 -wd4201 -wd4189 -fno-builtin
REM -STACK:0x100000,0x100000 is setting function stack default to 1MB. Can increase this if we need to. Keep in mind though this also increases default stack size for all threads created
set linker_flags=-subsystem:windows -machine:x64 -incremental:no -opt:ref -debug:full -ignore:4099 -NODEFAULTLIB -STACK:0x100000,0x100000
Related
I am trying to compile a C program using gcc with optimization enabled.
gcc [name] -lm
works fine, but as soon as I add -O3 it gives me this warning:
warning: ignoring return value of ‘scanf’, declared with attribute warn_unused_result [-Wunused-result]
What am I missing here?
Why does this warning depend on the optimization level? [from comment section]
The main reason is that there are certain analysis enabled by different optimization levels.
The absolute best way is to do as the compiler tells you. Not checking the return value of various functions is something that is the source of many bugs. Just do something like this:
if(scanf("%d%d", &x, &y) != 2) { /* Handle error * }
and the warning will disappear.
If you instead decide that you know better than the compiler and simply want it to shut up, then you can also do as the warning tells you, even if it's not so obvious how it is done. Use this code:
#pragma GCC diagnostic warning "-Wunused-result"
That method can be used for a lot of warnings. In this particular case, it's however more conventional to cast the result:
(void)scanf( ...
but that does not always work.
Do note that all of these have their pros and cons. If you for instance for some reason are able to prove that all input from stdin will have the right form and that you never fail to read from it, then by all means, deactivate the warning. Another thing could be that you have special needs, like extreme performance and/or very limited resources, or maybe some other reasons, it could be a wise choice to do a risk analysis for it and see if the risk is acceptable.
But as a general rule, do not inactivate compiler warnings unless you are very, very certain that the thing the compiler is warning about will not cause trouble. "I don't want to see a a lot of warnings" is not a good reason for disabling warnings.
This happens when you compile it with -O2 or -O3 optimization level.
You can either suppress the warning by using the following gcc command options
gcc -Wall -Wextra -Wno-unused-result file.c -o file
or you can also declare a variable (if no memory constraints) to store the return value of scanf() which avoids the warning.
int unused __attribute__((unused));
unused = scanf("%d",&e);
I'm running a CTF and I am currently writing a problem that exploits C's gets function. I understand that the function is deprecated and dangerous and I would never use it in any other circumstance. Unfortunately, gcc compiles my code and when I run the binary when the gets function is hit, I get a friendly error message:
warning: this program uses gets(), which is unsafe.
This would normally be great, because it warns you that gets is unsafe, but unfortunately, in my CTF, I think that this error message makes the problem a bit too easy. Do you know how I would go about disabling this warning? Thanks!
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Note: I just realized that your question title seems to be misplaced - The warning you got is from macOS about executing a program which uses gets(). It has nothing to do with the compilation by using GCC.
:-/ Any way, I let my answer alive for reference.
Just as comment: I googled a bit about what you are looking for, but there seems to be no reliable way to disable this warning when executing the program. One suggested rebuilding /usr/lib/libSystem.B.dylib without any result or experience if it indeed works, but I personally think this a bit too extreme and even can be harmful. - I do not recommend this technique.
If you really want to create an exploit program, try to rebuild gets() by a costum-made function and name the function a bit different, like f.e. gets_c(). This should be a workaround to disable this warning from macOS.
Old answer (regarding GCC itself):
First of all, you seem to be using a C99 or C89/C90-compliant compiler or alternatively compile with std=c99 or std=c89/std=c90 option, because only compilers conform to standards preceding C11 warn about gets() being deprecated.
ISO/IEC removed the gets() function in C11. If you would compile with a C11 or newer standard-compliant compiler, you would get an error about the implicit declaration of gets() when using it in the code instead:
"error: implicit declaration of function 'gets'; did you mean 'fgets'? [-Werror=implicit-function-declaration]"
If you want to suppress the warning at compilation, use the -Wno-deprecated-declarations option at compiling to disable the diagnostic for deprecated declarations.
From the GCC online docs:
-Wno-deprecated-declarations
Do not warn about uses of functions, variables, and types marked as deprecated by using the deprecated attribute. (see Function Attributes, see Variable Attributes, see Type Attributes.)
Source: https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Warning-Options.html
If you want to embed the suppression of the warning in your code use the approach used in David´s deleted answer implementing a suppression for -Wno-deprecated-declarations by using #pragma:
char str[256];
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
gets(str);
#pragma GCC diagnostic pop
I want to get rid of all implicit-function-declaration warnings in my codebase. But there is a problem because some functions are
programmed into the microcontroller ROM at the factory and during linking a linker script provides only the function address. These functions are called by code in the SDK.
During compilation gcc of course emits the warning implicit-function-declaration. How can I get rid of this warning?
To be clear I understand why the warning is there and what does it mean. But in this particular case the developers of SDK guarantee that the code will work with implicit rules (i.e. implicit function takes only ints and returns an int). So this warning is a false positive.
This is gnu-C-99 only, no c++.
Ideas:
Guess the argument types, write a prototype in a header and include that?
Tell gcc to treat such functions as false positive with some gcc attribute?
You can either create a prototype function in a header, or suppress the warnings with the following:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wimplicit-function-declaration"
/* line where GCC complains about implicit function declaration */
#pragma GCC diagnostic pop
Write a small program that generates a header file romfunctions.h from the linker script, with a line like this
int rom_function();
for each symbol defined by the ROM. Run this program from your Makefiles. Change all of the files that use these functions to include romfunctions.h. This way, if the linker script changes, you don't have to update the header file by hand.
Because most of my programming expertise was acquired by self-study, I intentionally have become somewhat anal about resolving non-fatal warnings, specifically to avoid picking up bad coding habits. But, this has revealed to me that such bad coding habits are quite common, even from formally trained programmers. In particular, for someone like me who is also anal about NOT using MS Windows, my self-study of so-called platform-independent code such as OpenGL and Vulkan has revealed a WORLD of bad coding habits, particularly as I examine code written assuming the student was using Visual Studio and a Windows C/C++ compiler.
Recently, I encountered NUMEROUS non-fatal warnings as I designed an Ubuntu Qt Console implementation of an online example of how to use SPIR-V shaders with OpenGL. I finally threw in the towel and added the following lines to my qmake .PRO file to get rid of the non-fatal-warnings (after, first, studying each one and convincing myself it could be safely ignored) :
QMAKE_CFLAGS += -Wno-implicit-function-declaration
-Wno-address-of-packed-member
[Completely written due to commends]
You are compiling the vendor SDK with your own code. This is not typically what you want to do.
What you do is you build their SDK files with gcc -c -Wno-implicit-function-declaration and and your own files with gcc -c or possibly gcc -o output all-your-c-files all-their-o-files.
C does not require that declarations be prototypes, so you can get rid of the problem (which should be a hard error, not a warning, since implicit declarations are not valid C) by using a non-prototype declaration, which requires only knowing the return type. For example:
int foo();
Since "implicit declarations" were historically treated as returning int, you can simply use int for all of them.
If you are using C program, use
#include <stdio.h>
I recently realized that I am not even in C99 mode after receiving the compile error
'for' loop initial declarations are only allowed in C99 mode
I found some advice on how to get to C99 via a quick search which has told me to go to Projects -> Properties... But alas, it is greyed out and I am not sure that is even the correct way to fix it (probably not available because my file is not a project, it is a normal source file). I have also seen a lot of similar questions saying to enable C99 mode so I have looked inside the compiler flags menu, but I cannot see anything about C99. I have tried some other flags such as In C Mode, support all ISO C90 programs..., but after I set this flag, I got more errors than I had before which seem to appear whenever the compiler finds comments inside main().
Note: Please don't just say to initialize the counter outside the for loop.
Update: While trying to compile outside of codeblocks with gcc, I tried
gcc -O2 -std=C99 filename.c, but received an error:
unrecognized command line option "-std=C99"
I use 64-bit Windows 7, CodeBlocks10.05, and GNU gcc.
For future reference, type in the flag -std=c99 in settings->compiler->other options which is not case-sensitive, however when compiling in a terminal the flag is case-sensitive. Thanks chris!
I'm trying to set option -fstack-protector-all in GCC 3.4.3 compiler for enabling some stack smashing protection scenarios. However when compiling with this i got error: unrecognized command line option "-fstack-protector-all"
. So seems this option isn't implemented in GCC 3.4.3 ?? or Am I missing something ?
If it is not implemented in older GCC compiler what is the best / easiest alternative to this ?
Or maybe some useful code pattern to implement stack-smashing protector in C code itself ?
Thanks
You seem to be only one minor version off a gcc version that seems to be able to provide you with this particular smash protection. I found this when googling:
http://www.research.ibm.com/trl/projects/security/ssp/
Maybe you could upgrade to that one (one minor number up) and still be compatible with your vendor?
Additionally, as at least for a number of years canary values are default set in gcc (no need to use the option you mention), have you looked at the disassembly of a simple program? If you see some storing/loading from a (gs) location near end of stack, it's already implemented.