--- In [email protected], "peternilsson42" <[EMAIL PROTECTED]>
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...so headers are not the
case here...
>
> #include <stdio.h>
> #include <string.h>
>
> If you don't then the signatures for the functions
> you use default to the wrong type.
>
> > int main(int argc, char *argv[])
>
> Not an error, but you only need...
>
> int main(void)
>
> > {
> >
> > char buff[80];
> > sprintf(buff, "hello world");
> > printf("%s\n", buff);
>
> More simply...
>
> char buff[80] = "hello world";
> puts(buff);
>
> > 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...."
> You probably didn't realise that because you didn't
> include the relevant header, so strcat defaults to...
>
> int strcat();
>
> ...instead of what it should be...
>
> char *strcat(char *, const char *);
>
> Had you included the header, the compiler is
> obliged to issue a diagnostic for the constraint
> violation of assigning a pointer to an integer.
>
> Note that the 1999 C standard requires named
> functions to be declared before use.
>
> > printf("%s\n", buff);
> > 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....
>
> > return 0;
> > }
>
> 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... ;-)
>
> --
> Peter
>
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... in this case, i
was just lost of words.. it was not my problem in the first place...
somebody had just asked me... in any case, thanks for the answers =)
