macOS Please help! Compiling C program on Mac

[bokbosky]

Hi guys,

I want to start programming in C on my MacBook. I tried all the ways I can, to compile the very basic program, but failed. Please help me.

#include <stdio.h>
main()
{
*printf("Hello world \n");
}

Error Message:
dhcp-018-125:Cfiles ram$ gcc -o rn1 world.c
world.c: In function ‘main’:
world.c:4: error: stray ‘\194’ in program
world.c:4: error: stray ‘\160’ in program

Methods followed: 3

1.

I tried writing this code in Textwrangler and then compiled using the option 'Run in the terminal' by adding 'shebang' (#! /bin/sh), code is compiled but could not find the output of printf statement,

Output:
Last login: Wed Jul 30 01:03:19 on ttys001
/var/folders/bM/bMtn-hXkGOmPCW7lipJokk+++TI/Cleanup\ At\ Startup/helloWorld-239090206.981.c.command ; exit;
dhcp-018-125:~ ram$ /var/folders/bM/bMtn-hXkGOmPCW7lipJokk+++TI/Cleanup\ At\ Startup/helloWorld-239090206.981.c.command ; exit;
logout

[Process completed]

Method 2 & 3:
Both of these 2 methods are similar in the way of compiling, in both the ways I used terminal, but the codes were written in textwrangler & textedit.

command in the terminal:
dhcp-018-125:Cfiles ram$ gcc -o rn1 world.c

Got the same error message:

world.c: In function ‘main’:
world.c:4: error: stray ‘\194’ in program
world.c:4: error: stray ‘\160’ in program

Guys, sorry for the long message, but all day I tried to compile with all possible ways, but no luck.

Any help will be appreciated.

 

[MrStevieP]

Hi guys,

I want to start programming in C on my MacBook. I tried all the ways I can, to compile the very basic program, but failed. Please help me.

#include <stdio.h>
main()
{
*printf("Hello world \n");
}

Error Message:
dhcp-018-125:Cfiles ram$ gcc -o rn1 world.c
world.c: In function ‘main’:
world.c:4: error: stray ‘\194’ in program
world.c:4: error: stray ‘\160’ in program

Methods followed: 3

1.

I tried writing this code in Textwrangler and then compiled using the option 'Run in the terminal' by adding 'shebang' (#! /bin/sh), code is compiled but could not find the output of printf statement,

Output:
Last login: Wed Jul 30 01:03:19 on ttys001
/var/folders/bM/bMtn-hXkGOmPCW7lipJokk+++TI/Cleanup\ At\ Startup/helloWorld-239090206.981.c.command ; exit;
dhcp-018-125:~ ram$ /var/folders/bM/bMtn-hXkGOmPCW7lipJokk+++TI/Cleanup\ At\ Startup/helloWorld-239090206.981.c.command ; exit;
logout

[Process completed]

Method 2 & 3:
Both of these 2 methods are similar in the way of compiling, in both the ways I used terminal, but the codes were written in textwrangler & textedit.

command in the terminal:
dhcp-018-125:Cfiles ram$ gcc -o rn1 world.c

Got the same error message:

world.c: In function ‘main’:
world.c:4: error: stray ‘\194’ in program
world.c:4: error: stray ‘\160’ in program

Guys, sorry for the long message, but all day I tried to compile with all possible ways, but no luck.

Any help will be appreciated.

The compiler is telling you where to look, line 4. My observations are as follows

1) Whats the * doing in front of the printf?
2) Why does main not have a return type? It should at least be void.
3) Why does main not have any parameters? You could put void, or better would be main(int argc, char** argv)


Address these issues and the compiler should give you the all clear. You might want to turn on the -pedantic mode so that it tell you about every problem.

Hope it helps,

Steve

 

[newb16]

world.c:4: error: stray ‘\194’ in program
world.c:4: error: stray ‘\160’ in program

* in front of printf ( although wrong ) should not yield such errors. Most likely there are some wrong characters in the string or printf name itself. Change the string to empty one ans try.

 

[AUFan]

From what little C experience I have, I see two problems.

#1 -- you need to put int before the main function.

 int main()

#2 -- no * before printf. that will generate an error.

 printf("Text here.\n");

Your code should look something like this:

#include <stdio.h>

int main()
{
     printf("Hello world!\n");
     return(0);
}

I'm also a newbie C coder and it's a lot of fun. To write my stuff I'm using TextWrangler and compiling with gcc. For compiling have you tried:

 gcc -o programname filename.c

I've compiled all my programs to date that way and haven't had any problems.

 

[sord]

* in front of printf ( although wrong ) should not yield such errors.

Wrong -- it is not valid and does produce an error.

#1 -- you need to put int before the main function.

Also wrong, you do not technically need a return type (although it is bad practice to not have one)

3) Why does main not have any parameters? You could put void, or better would be main(int argc, char** argv)

Again, bad practice to have it empty, but not necessary.

In the end, the following code is valid and compiles properly:

#include <stdio.h>
main()
{
     printf("Hello world \n");
}

The only necessary change is removing the asterisk.

 

[Cromulent]

Also wrong, you do not technically need a return type (although it is bad practice to not have one)

As stated in another thread I posted in; it is actually wrong as of C99 being published.

 

[sord]

As stated in another thread I posted in; it is actually wrong as of C99 being published.

To quote C99 section 5.1.2.2.1:

The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:

int main(void) { /*... */ }

or with twoparameters (referred to here asargcandargv, though anynames may be
used, as theyare local to the function in which theyare declared):

int main(int argc, char *argv[]) { /*... */ }

or equivalent;9) or in some other implementation-defined manner.

Not giving a return type for main means it should default to int, because the return type of main is int. This means a compiler can either error, or default it to int. In the case of gcc, it defaults (meaning main without a return type is valid, though not having a return type is just an illusion)

 

[Cromulent]

To quote C99 section 5.1.2.2.1:

Not giving a return type for main means it should default to int, because the return type of main is int. This means a compiler can either error, or default it to int. In the case of gcc, it defaults (meaning main without a return type is valid, though not having a return type is just an illusion)

Just because it works in GCC does not make it correct. The standard clearly states that anything outside of the two examples shown in your post is implementation specific and therefore not standard C (although allowed by the standard).

Edit : Small addition.

 

[JVene]

Pardon me for chiming in here, but the objective, I think, is to deal with the OP's question.

To that end I think bokbosky has received a significant education in how there has been an evolution in the standard, and compilers differ in how they are written to interpret the standard.

To avoid confusing a student, however, let me point out that what may be acceptable to one compiler, and what was once considered a standard practice, should be understood with respect to where we are today, and how professionals will expect an engineer to write. Valid or not (to a particular compiler or timeframe), "main()" is not an acceptable 'main' function, and hasn't been for several years now, simply because a great many modern compilers will either refuse it or warn about it.

Almost two decades ago, I wrote an application in AIX's XLC compiler under contract. I inadvertently left a bug in the code where a function that returned int was allowed to return without a return statement. In XLC, the compiler assumed the return would be zero, and the program functioned that way for 17 years.

Recently, I had reason to update the code for my client. The XLC compiler had been replaced years ago, and a recent GCC (4.2.x) complained. The GCC version gave a warning, if memory serves, and produced an executable where the return from this function was a random value. Obviously the code didn't work correctly, and the fix was simple.

My point is, I should have issued a return 0;, but the code had operated for years under the assumption made by one compiler, which was refused by another compiler.

While I might forgive myself for an error made over 17 years ago, it would have been more professional if I had not committed the error, and both compilers would have handled the code the same way.

I think it is important for a student to learn to write code that is compliant with the recent standard which is expected to compile and operate the same on at least most compilers, if not all, that they're likely to encounter from now on. However, I give a nod to the fact that on rare occasions a professional is called upon to write for and use a very old compiler which will differ, and this is simply the way things are in professional development.

Since so many amateurs have, eventually, worked their interest into a career, I don't see that even amateurs are served by declaring code that won't compile on a number of compilers, and that is not acceptable under a great many circumstances, as somehow valid because there was a time when it was considered valid. A history lesson aside, I think it is ultimately misleading.

 

[Sander]

Since so many amateurs have, eventually, worked their interest into a career, I don't see that even amateurs are served by declaring code that won't compile on a number of compilers, and that is not acceptable under a great many circumstances, as somehow valid because there was a time when it was considered valid. A history lesson aside, I think it is ultimately misleading.

Quoted for truth.

Too often I see the advice (even in books!) that when you want to know what a certain expression does, simply try it out! This is very dangerous, especially when people start going into "undefined" areas (like

i++ = ++i;

and things like this). They try it out on their particular compiler, note what happens, and assume this is "the truth".

By the way, I even see this in production code. Everytime we upgrade to a newer compiler, we have to spend quite a bit of time going through the code to fix things which were "assumed to work". Luckily, it's usually the case that the newer compiler emits warnings where the old one would let it slip.

 

[lazydog]

Hi

One, very small, pedantic point raised for the benefit of the OP:-

return( 0 ) ;

looks like a function call when in fact, return is a statement ( syntax is return expression ; ). The brackets in the above case are in fact part of the expression and not needed.

good luck with learning C!!!

b e n

 

[ctalibard]

Encoding issue?

Whilst I agree with all the comments on the style/validity of *printf and the main() function definition/prototype. It's far more likely that a completely different problem is causing the specific compiler errors here.

* Most likely there are some wrong characters in the string or printf name itself. Change the string to empty one ans try.

This it more like it, but I reckon it's more likely that the "" quotes are the offending characters.

Is it not the case that gcc will be expecting ASCII (7-bit) for C? Both 0x194 and 0x160 are out of that range, and are most likely what happens when your text editor outputs 'sexed' quotes (i.e. 66, 99 style) in UTF-8 (or some other encoding).

Ensure that your editor is set to output ASCII or at least 8-bit ISO Latin 1 encoding and try saving your file again. This should ensure that the quotes are both 'sexless' and within ASCII range. That should at least eliminate any encoding issues

 

[grim42]

There is a setting in TextWrangler's preferences called "Smart Quotes" (in the Editor Defaults section) that turns "normal" quotes (ASCII character 34) into curly word-processor style quotes.

I think that is the problem here.