"int21h_d" <[EMAIL PROTECTED]> wrote: > "peternilsson42" <peternilsson42@> wrote: > > "int21h_d" <int21h_d@> wrote: > > > > > > can someone explain why the "thequickbrown..." doesnt > > > concatenates after the "hello world", that is, "hello > > > worldthequickbrownfox...." ??? > > > > You _need_ to include certain headers before you can > > expect the code to work at all... > > it was supposedly to be a code snippet anyway...
Was it expected to be correct? If not, please don't waste our time and yours. > so headers are not the case here... You still don't realise. The presence or absence of headers _changes_ the question you are asking. It affects the subsequent code and how it's interpreted by a compiler. Especially a C90 compiler. Leaving out headers is big mistake. Unlike C99 and C++, in C90 it's often an undiagnosed mistake. <snip> > > > buff[strlen(buff)]=strcat > > > (buff,"thequickbrownfoxjumpsoverthelazydog"); > > > > What do you expect this to do? You are attempting to > > assign a pointer to a character! > > well, what had happened(output) here is "hello world > hequick...." I asked you what you _expected_ to happen. We all learn by our mistakes, but trying to learn only through deliberate mistakes is a foolish endeavour. Serendipity is rare, and with C, 'experimentation' is more likely teach you the wrong thing than the right thing. <snip> > > > getch(); > > > > Non standard function that has a perfectly useable > > standard alternative, namely getchar(). That said, > > learn to run your programs from a DOS emulator, > > rather than from IDE that closes the window when > > the program finishes. > > use of standard functions are not the case also.... They are when some of the people you're seeking help from are on boxes that don't have getch(). Why limit the potential number of responses? > > It makes no sense to talk about why a broken program > > didn't work. Undefined behaviour means _anything_ > > can happen. > > > > Curiosity is a useful trait, but I'd rather spend two > > hours writing useful code that works, than two hours > > studying why a broken piece of code happens to behave > > a certain way, on a specific machine, on a specific > > compiler, at a specific time of day, and phase of the > > moon... ;-) > > well, Peter, i agree w/ you in spending your time, > however, it will not be right either if someone had > asked you such stuffs and answer him that the code > wont work because it wont work... I did more than that. I pointed out several mistakes, consequenses, and alternative practices. It's up to you whether you focus on that, or your ego. One of these choices will help you become a better programmer. ;-) > in this case, i was just lost of words.. It wasn't what you wanted to hear. But I (still) believe it's what you needed to hear. > it was not my problem in the first place... > somebody had just asked me... Now that is not relevant here. The question was asked and answered. Who asked it isn't important. OPs are not the sole stakeholder when a question is asked in a forum of 10000 people, most of whom are newbies. > in any case, thanks for the answers =) If my post discourages just one person from trying to learn C by guesswork and broken samples, then it will be worth it. If you want the friendly answer: The code has no well defined behaviour. So I can't answer why the program did what it did on your machine. But that answer doesn't convey the message that this sort of examination of C programs is deeply flawed. -- Peter
