We have started C programming in my Uni, and I appear to have fallen at the first hurdle. My very simple program will not print to the terminal. The code:
#include "stdio.h"
int main(){
printf("Memory size for type %s = %lu \n", "double", sizeof(double));
return 0;
}
I have used all my google-fu, and have only found that I apparently should use vprint, but it won't take three arguments, only two. Also, bizarrely, printing to a file works! See screenshot:
Terminal screenshot
The format specifier for size_t(the return type of sizeof) is %zu.
printf("Memory size for type %s = %zu \n", "double", sizeof(double));
Alright, apparently, when I simply run the program, Clang prints the output to a.out in the same directory as the code, and there's nothing I can do about it. Whatever, as long as the code works - means I can turn it in, and I'll be checking my work with ./a.out.
According to your screenshot, it appears that there is a misconception here :
gcc 1.c
gcc is used to compile the program (creating the executable, here using the source file 1.c), not to run it. The program might have been compiled under the name 'a.out'.
When you compile your program using :
gcc 1.c -o 1.txt
You are actually compiling the program with gcc and, using the option -o, creating the executable under the name 1.txt (a program can be named whatever you want, or almost)
Then when you type
./1.txt
you are actually running the program (1.txt) and you have the expected output.
Related
I need to get this stripped-down C program working on Windows 7 using MSys2's gcc toolchain:
#include <stdio.h>
void wmain(int argc, wchar_t *argv[])
{
for (int i = 1; i < argc; i++)
wprintf(L"%s\n", argv[i]);
}
The code compiles with
gcc -Wall -municode -O2 -march=x86-64 -m64 test.c
but gives me the following output
>> ./a.exe kk лл
k (!)
:?:?
I have the following questions:
What am I doing wrong?
How would I downgrade the compiler to
version, say, 9.x, or 10.1? (I'm under the impression that the very
same program compiled about one year ago used to work correctly)
Edit [1]: Meanwhile I managed to set up a new MSys2 environment using gcc 9.3. The "error" persists, so it's not the compiler.
Edit [2]: "Some programmer dude" (cmp. below) described the "immediate" solution (THX!).
Even for the wide-character wprintf the format %s is for narrow character strings.
You need to use %ls to print wide-character strings:
wprintf(L"%ls\n", argv[i]);
However this might still not be enough, as the actual encoding of the input (including arguments) might not be what's expected. You need to take into account the encoding used by the terminal the program is running in.
Following program with putw is not writing the required data in the file.
#include <stdio.h>
int main(void)
{
FILE *fp;
fp = fopen("a.txt", "w");
putw(25,fp);
putw(325,fp);
putw(425,fp);
fclose(fp);
return 0;
}
Program is compiled and executed like the following
gcc filename.c
./a.out
It is writing something in the file. Also if we read the integer using getw(), it is reading the value which is not available in the file. Even it is not the ASCII value.
When it is compiled with gcc filename.c -std=c99, it is showing implicit declaration warning error.
Is it required to link any library files to use putw/getw in c.
There is no function called putw in standard C, which is why you get compiler warnings. You probably meant to use putwc in wchar.h.
putw is an ancient function that exists on some platforms. Use fwrite and fread instead. You should also check the return value from putw. It may be telling you why it is failing.
I’m trying to make a C program which is prompting the user to type a message from the console and then show that message the user has typed, as in the following example:
C:>promptTest
type your message >>>> test
typed : test
C:>
This is my code:
#include <stdio.h>
#include <string.h>
int main(){
char msg[32];
printf("type your message >>>>\t");
fgets(msg,sizeof(msg),stdin);
msg[strlen(msg) - 1] = '\0';
printf("typed : %s\n",msg);
return 0;
}
It can be built on both Windows7 and CentOS and it can be run normally on Windows like above.
However, it can’t be run on CentOS. I mean nothing accepts any message from the prompt like below:
$ ./promptTest
type your message >>>> test
typed :
$
How can I fix this?
Here is information about my machine.
$ cat /etc/redhat-release
CentOS release 6.4 (Final)
$
$ arch
x86_64
$
strlen() returns size_t not int.
Printing size_t on a 64bit IXish system using %d might fail, as the former most likly is 64bit while the latter expects 32bit.
So at least on a 64bit IXish system instead of
printf("### buf(%d) = %s\n",strlen(buf),buf);
printf("### message(%d) = %s\n",strlen(message),message);
do
printf("### buf(%zu) = %s\n",strlen(buf),buf);
printf("### message(%zu) = %s\n",strlen(message),message);
As a (ugly) workaround you could also cast strlen() down to int.
printf("### buf(%d) = %s\n", (int) strlen(buf),buf);
printf("### message(%d) = %s\n", (int) strlen(message),message);
This workaround however assumes no string being longer then INT_MAX.
I found the solution.
CL+LF coused this matter.
see Controlling prompt for command line
So I've been trying to get this code to compile using a gcc compiler using c (I found lots of references to c++ but none to c so I asked this) I kept on getting the error Badly placed ()'s every time I go to run the program. So I simplified it to a very simple Hello World test program and I still get the same error.
What could be causing this error?
#include <stdio.h>
int main(int argc, int* argv[])
{
printf("Hello World\n");
return 0;
}
It seems that you are not trying to execute the compiled binary, but that you have a system that runs a tcsh and you are feeding the C source code directly into that shell:
> tcsh /tmp/badly.c
Badly placed ()'s.
A C program must first be compiled to a binary (here: /tmp/badly), and then you have to execute that binary:
> gcc /tmp/badly.c -Wall -o /tmp/badly
/tmp/badly.c:3:5: warning: second argument of 'main' should be 'char **' [-Wmain]
> /tmp/badly
Hello World
As ouah already noticed in his answer, with the -Wall argument to gcc you also get the informative message that the parameters of your main function are wrong.
I'm compiling the below C code with gcc. No errors are thrown during compilation or at runtime. I ran through the code with gdb, and the answer given in sum is correct at the end, yet the printf() does not display anything on the screen. I've tried all sorts of combinations of fprintf(), printf(), and fflush(), but nothing works.
What do I need to change so the program will print the result to stdout?
#include <stdio.h>
#include <stdlib.h>
int main()
{
int num = 9;
int i, sum; i = 1, sum = 0;
while (i < 2 * num) {
sum = sum + i * i;
++i;
}
printf("sum: %d\n", sum);
fflush(stdout);
return 0;
}
The code is correct, and should print sum: 1785 for any conforming implementation.
This is a guess (update: which turns out to be correct), but ...
You've named the source file test.c, and you compile it with:
$ gcc test.c -o test
(or something similar) and execute it with:
$ test
which produces no output.
The problem is that test is a standard Unix command (and also a built-in command in some shells). When you type a command name to the shell, it first looks for built-in commands, then for executables in directories specified in your $PATH environment variable.
To execute a command in the current directory, prepend ./ to the name:
$ ./test
sum: 1785
$
This applies to any command in the current directory. There are so many built-in commands that you can't reasonably avoid colliding with them. Cultivating the habit of running executables in the current directory by typing ./whatever means that name collisions don't matter.
(Don't be tempted to add . to the front of your $PATH; that's dangerous. Think about what could happen if you cd into a directory and type ls, if there happens to be a malicious ls command there.)
There is nothing wrong with your program. It has to work. Try running it with redirection:
./a.out > myout
..and see if you get any output. If not, I'd suspect there is a problem with some kind of standard library mismatch.
Another option to check would be to build using SUN C compiler as opposed to gcc and see if that works. If it does, gcc is the culprit.