When I build and run C using Sublime Text 3, a warning message show up.
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
Actually, it is my first time to use Sublime Text 3 for C programming, so I wonder how to take care of this warning message.
My source code and the output are as below.
soruce:
#include <stdio.h>
int main(void) {
int a = 3;
printf("%d\n", a);
}
output:
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
3
[Finished in 0.1s]
These are executed in Mavericks(Mac OS)
Please let me know the solution.
Does this mean you have saved your file as file.cpp instead of file.c? (Sorry, I can not comment, I have few points.)
Related
I am incredibly new to the C language: I am trying to run sample C programs from codecademy, such as the hello world command below:
#include <stdio.h>
int main() {
// output a line
printf("Hello World!\n");
}
Bottom line is, every time I try to run any code in my macOS terminal, I always get the following error:
zsh: parse error near `\n'
What can I do to resolve this problem?
c is a language where you need to compile the code you've written. You do that by starting a C compiler and give the file containing your C code as input.
Example:
File: myfirstcprogram.c
#include <stdio.h>
int main(void) {
printf("Hello World!\n");
}
Then at the zsh prompt, invoke the compiler:
cc myfirstcprogram.c -o myfirstcprogram
-o myfirstcprogram is here an argument to the compiler telling it what to call the final program.
cc may be clang or gcc or any other compiler you've got installed if cc isn't already linked to the proper compiler.
When the compilation is done, the executable myfirstcprogram should have been created. You can now run it from your zsh prompt:
./myfirstcprogram
You can run it without recompiling it as many times as you like. Only when you change the source code (myfirstcprogram.c) do you need to compile the program into an executable again.
I am using Vsc to write my program in C, the program should return an error but nothing is shown, only the final code is provided (code = 3221225477), how can I get the error displayed?
The final output is: [Done] exited with code=3221225477 in 0.569 seconds
#include <stdio.h>
#include <stdlib.h>
int main(){
char x = 'a';
printf("%s", x); //Error cause i'm using %s for a char
}
P.s. I have already installed .Run and the C / C ++ extension
The Microsoft C/C++ extension if configured properly (problemMatcher in tasks.json) should also trigger similar errors based on the compiler you select.
After investigation, you might get some help from the clangd extension.
Install the extension in VS Code from https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.vscode-clangd
Open your project folder in VS Code and open the source file (like main.c).
Then this extension should run clangd in the background and show a warning "Format specifies type 'char *' but the argument has type 'char' (fix available)".
I am trying to run a simple program below on my mac using CodeBlocks IDE:
1. #include <stdio.h>
2. int main()
3. {
4. // printf() displays the string inside quotation
5. printf("Hello, World!");
6. return 0;
7. }
but I get the following error:
error: expected identifier or '('
As the machine is trying to compile, I think gcc compiler is working fine.
Remove the line numbers, that's the problem.
try in different IDE and find out where the problem is whether in Codeblocks IDE configuration or with the compiler itself.
Here the concise c code:
#include <stdio.h>
int main()
{
printf("abcdefg\n");
return 0;
}
when I open it with ollydbg, and then type E (executable module), right click the a module and select 'view executable file'. it will show the below window:
However, when I ctrl + B search for the 'printf', I got three result (ctrl + L will find the next)
My question is:
In my code is only one 'printf' function, why can I find 3 'printf' in the ollydbg.
My guess is, when you include stdio.h it must contain more occurrences of printf string, compiled source is not only your source but also everything you include.
I don't think names of functions should be included in the binary file (but I'm not an expert), I think only reason they are there is you compile it with debugging options on. You can check it easily by compiling the binary without debugger on and checking the executable with some hex editor.
I recommend to study how compilers work?. The link I sent might be good place to start and study.
Okay, so this is going to sound like a silly question, yet I am stuck : I have trouble reading the value of a variable during a lldb debugging session (things work fine with gdb).
I have found posts from other people who had encountered the same error message than myself, but the difference is that I can't even figure out how to print out the value of the simplest form of variable.
To better express my problem, I will consider a very simple example here. We have a file "main.c" containing the following code :
#include <stdlib.h>
#include <stdio.h>
int main(void) {
int a = 1;
int b = 2;
int c = 0;
c = a + b;
c = c*b;
printf("c = %d\n", c);
return 0;
}
I compile it using :
user#machine ~ $ gcc -g main.c
A binary file named
"a.out"
is generated
I then ivoque lldb :
user#machine ~ $ lldb-3.4 ./a.out
I want to stop at line 9 and read the value of c. Therefore, I start by adding a breakpoint :
(lldb) breakpoint set -f main.c -l 9
Then I run the code :
(lldb) run
Up until now, every thing goes as expected. Now comes the tricky part : I want to read the value of variable c. Therefore, I write :
(lldb) print c
And lldb returns me :
error: use of undeclared identifier 'c'
error: 1 errors parsing expression
Of course :
(lldb) expression c
returns exactly the same error message.
Is there anything that I missed ? Any help would be very much appreciated.
My setup :
lldb : "lldb version 3.4 ( revision )" (package v. : "3.4~svn183914-1ubuntu1")
gcc : "gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1" (package v. : "4.8.1-2ubuntu3")
(my repositories are the ones provided by linux mint 16 by default)
Some more information following answer from #Sean Perry :
1: It seems that appending option -O0 does not change the debugger's behaviour.
2: I also tried to use the following dummy code instead of my previous one
#include <stdlib.h>
#include <stdio.h>
int main(void) {
long a = 1;
long b = 2;
long c = 0;
c = a + b;
c += (long) &c;
printf("c = %ld\n", c);
return 0;
}
I am not certain that is what #Sean Perry meant by "using pointers", but I suppose it must prevent code optimisation anyway since the address of variable c (more or less) randomly changes for each run of the binary file.
3: Eventually, I noticed something interesting :
compiling with gcc [-g -O0] then debugging with gdb : works
compiling with gcc [-g -O0] then debugging with lldb : does not work
compiling with clang [-g -O0] then debugging with gdb : works
compiling with clang [-g -O0] then debugging with lldb : works
edit1 : reply to #SeanPerry
edit2 : distinguishing the software version from the package version
Seems like this was a specific issue when using gcc 4.8.1 and lldb-3.4
Using gcc-4.8.2 and gcc-4.7.3 works fine.
The best way to investigate the behavior you're seeing is to look at the debug info. On a Mac OS X system, you'd run dwarfdump on the .dSYM bundle or on the .o file if you didn't create a dSYM. The debug information has the instructions from the compiler to the debugger about where to find variables.
In a live process, with lldb, you can have lldb show you where all the local variables are stored (expressed in the DWARF location expression language) with image lookup -v -a $pc (or im loo -va $pc for short).
If there's a program where gdb can't print a variable and lldb at the same pc address cannot, that sounds like it could be an lldb bug. The debug information is the ultimate truth (as far as the debugger is concerned) about where variables are stored and how long they are "live". In optimized code, they may be live for very short sections of your function.
From a hack point of view, the real source of truth is to read the assembly code. Often, under optimization, the compiler doesn't track the location of the variables as well as it could -- it may say that a variable is unavailable at a given pc address, but if you read the assembly closely enough, you might find a copy of the last value still saved on the stack & such.
This code is so simple I bet llvm has removed the variables completely. Try compiling with optimizations disabled (-O0) and see if it helps. Beyond that, use a pointer or do something a little more complicated so the compiler does not removed your math and replace it with precomputed values.