Please help! Compiling C program on Mac

Discussion in 'Mac Programming' started by bokbosky, Jul 29, 2008.

  1. bokbosky macrumors newbie

    Joined:
    Jul 29, 2008
    #1
    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.
     
  2. MrStevieP macrumors newbie

    Joined:
    Feb 27, 2008
    #2
    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
     
  3. newb16 macrumors regular

    Joined:
    Feb 27, 2008
    #3
    * 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.
     
  4. AUFan macrumors newbie

    Joined:
    Feb 2, 2008
    #4
    From what little C experience I have, I see two problems.

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

    Code:
     int main() 
    #2 -- no * before printf. that will generate an error.

    Code:
     printf("Text here.\n"); 
    Your code should look something like this:

    Code:
     
    
    #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:

    Code:
     gcc -o programname filename.c 
    I've compiled all my programs to date that way and haven't had any problems.
     
  5. sord macrumors 6502

    Joined:
    Jun 16, 2004
    #5
    Wrong -- it is not valid and does produce an error.

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

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

    In the end, the following code is valid and compiles properly:
    Code:
    #include <stdio.h>
    main()
    {
         printf("Hello world \n");
    }
    The only necessary change is removing the asterisk.
     
  6. Cromulent macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #6
    As stated in another thread I posted in; it is actually wrong as of C99 being published.
     
  7. sord macrumors 6502

    Joined:
    Jun 16, 2004
    #7
    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)
     
  8. Cromulent macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #8
    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.
     
  9. JVene macrumors newbie

    Joined:
    Jul 22, 2008
    #9
    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.
     
  10. Sander macrumors 6502

    Joined:
    Apr 24, 2008
    #10
    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

    Code:
    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.
     
  11. lazydog macrumors 6502a

    Joined:
    Sep 3, 2005
    Location:
    Cramlington, UK
    #11
    Hi

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

    Code:
    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
     
  12. ctalibard macrumors newbie

    Joined:
    Aug 1, 2008
    Location:
    London
    #12
    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.

    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
     
  13. grim42 macrumors newbie

    Joined:
    Jun 27, 2008
    Location:
    Cape Town, South Africa
    #13
    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.
     

Share This Page