Print slashes using C

I want to print 4052 slashes using this C program.

#include <stdio.h>

void main()
{
int i;
for (i=0; i<4052; i++)
printf ("/");

}

When i compile this via gcc am getting this error :

Can anyone point out what am doing wrong?

Try:-

#include <stdio.h>

void main()
{
        int i;
        for (i=0; i<4052; i++)
        {
                printf ("/");
        }
}

It worked man thanks a lot!! can you tell me whats the difference between my program and yours? I tried to put curly braces earlier but didn't work

I don't see any.

In fact, your program works.

Did you post it completely as-is or clean it up?

My program was correct but didn't work for some strange reasons. After I cleaned it up (added tabs and braces) it worked perfectly.
thank you for reply mate

Very odd. I copy-pasted it and it just worked here. Oh well!

I don't believe that the program in post #1 generated the warning in the screenshot. Note that the warning uses the word "parameter", which is a strong clue. I'll wager that the program that actually generated that message defined main() using pre-ANSI syntax, which is what happens if int i; is moved up a line, so that it resides outside the braces.

void main()
int i;
{
    ...
}

Regards,
Alister

(Apologies for any typos.)

There is the possibility of the compiler itself compiling oddly...

I wrote a simple C proggy to R/W from/to memory for the AMIGA and it compiled and ran perfectly using Dice-C but failed to even compile on VBCC... So I set about doing the subtleties of each compiler until both gave the correct working results...

I then attempted to compile the same finalised source code on Windows VC6 and gcc on Knoppix 3.?. They compiled perfectly but did not run for obvious reasons...

So maybe the compiler is a little _pedantic_ and requires _its_ correct grammar...

;o)

There's usually a subset that will work fine in any of them. The trick is NOT using Microsoft's preferred structures but finding others they haven't managed to break yet...

It's difficult to imagine the OP's program was actually broken.

There's noting wrong with the code in post #1. Since whitespace is not relevant to C, there is no functional difference between the original code and what you posted in post #2.

While compilers often make extensions available, and while some aspects of standard C are implementation-defined, there is nothing in the OP's code that falls into either category.

The simplest and most likely explanation is that the OP did not post the code that generated the message. Perhaps a slight difference went unnoticed and was lost during debugging.

Moving int i; up a line, to create a pre-ANSI function definition, causes gcc 4.1.2 to produce an identical message.

Regards,
Alister

Hi alister...

I never wrote that there was! I only used one word in my original reply "Try:-".

Again I never quoted that it was relevant. The difference is I never make assumptions without quoting them. Hence my last reply; defferent compilers for the same language DO give differing end result executables on the same platform.

Although I rarely touch C(++) these days I never trust any C compiler and always compile using different platforms. It does not matter that some source code might NOT run on some platforms - for example R/W from/to memory as some machines do not have MMUs... Machines with MMUs WILL give Segmentation fault(s) but that does not mean the code is faulty just that the platform with an MMU creates the event.

My modified code just made it much more easy to read and seemed to help the guy in question and that is all that really matters - is it not?

I am now clear...

I've programmed C in DOS, Windows, Linux, Solaris, WinCE/ARM, and a few embedded platforms, building and/or using libraries that port between most or all of those. There are ways to write portable C code.

Writing to static strings will segfault on some platforms as you mentioned. The answer is to not do that; it's always been a dirty trick, technically speaking, but some compilers just happen to let you get away with it.

Not when the original question remains unresolved. I am completely certain now, that the code he posted is not the code that caused the error. So the 'solutions' are misleading at best.

You misunderstood me. I wasn't suggesting that you had made either assertion. I mentioned the code's correctness and whitespace's syntactical irrelevance only to point out that while your code suggestion appears to have fixed the problem for the OP, it could not have done so unless there is a very, very fundamental bug with a very popular and tested compiler -- a bug in which the presence of whitespace where it should not have any effect is the difference between code that compiles and code which does not; this is not impossible, but it is highly unlikely (particularly when transposing two adjacent lines of code produces an identical error message).

Regards,
Alister

Hi Corona688...

The problem is unless we know that for a fact then the ONLY assumption we can come to is the compilation itself.

As alister has pointed out, the given compiler has had _eons_ of proof tesing but that does not make it entirely bullet proof. Assuming the OP's code IS as he originally wrote it and he compiled it the way he did, giving the result on screen as shown, then perhaps - just a miniscule perhaps - there might be a very rare bug in the compiler...

I would not want to put my life on it, but the only real test is for the OP to go back to his original code and see if he can recreate the same error...

Anyhow as a mere amateur I do trust you professinals and your replies and will bow out gracefully... ;o)

Bye...

Sorry, I completely disagree.

When bringing programs here, posters often boil them down to the minimum possible since they just want help with that specific aspect. Unfortunately, not understanding the error means they don't know which parts are relevant, and the problem gets stripped out with the rest.

Same with data processing. People will post lovely-looking split-across-lines XML, ask "how do I remove these two lines" and complain when your program doesn't work with data all crammed on one line.

And so forth. This happens more often than it doesn't.

Well, it seems like magic, but is much fussier! That is one of the first things you learn! If you believe in magic, it takes longer!

Then throw in that there are a few ways that work, some unstable, and infinite ways for it to be messed up, somewhat like integral calc. The dark side of the force is strong, but not very productive.