Programming

(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...