void strcpy(char *s, char *t)
{ while ( (*s++ = *t++) != `\0);}i saw this code in a particular book.....
in the what does the assignment statement (*s++=*t++) return each time it gets executed........
all along i was thinking that the assignment statement return a 0 or 1 based on whether the assignment statement worked or not.... can somebody help me clarify my misconception.....
Jump to Post> Making your code not portable.
AFAIK, the code is portable, the behavior is undefined. Though it might work for you on each run, the same can't be said about it on another machine, compiler or architecture.
Jump to Post> However I thought that behavior underfined ment that the compiler
> doesn't know what to do, therefore it would not compile.
You are getting confused between the two of them. Using clrscr() is what constitutues non-portability since it is available only on Borland Compilers and is not a part …
Jump to PostI don't like the explanation you've received for "undefined behavior". What this means is the C Standard has not defined the operation, and what it is supposed to do. Therefore, any given compiler can do what they want. For
fflush(stdin), the compiler designers can write the compiler to:
1) …
Jump to Post> However I thought that behaviour undefined ment that the compiler
> doesn't know what to do, therefore it would not compile.
You are getting confused between the two of them.Good that I asked. Now I can see how bad it is. It's at run time that the behaviour …
Jump to PostNice work Samarium resurrecting a 5-year-old thread that nobody cares about any more.
It doesn't return anything, the comparison just uses the value of *s to control the loop. The moment it equals to '\0' i.e. the moment the null terminator character is copied from the destination string, the condition *s != '\0' becomes false and the loop breaks.
>what does the assignment statement (*s++=*t++) return each time it gets executed
It doesn't return anything. An assignment expression evaluates to the new value of the left-most operand.
A slightly modified version of it. Now indeed the function returns something.
/*
* char *stringcpy( char *s, char *t )
* copy a string into another.
* parameters:
* accepts two strings as arguments.
* returns:
* a pointer to the first string.
*/
char *stringcpy( char *s, char *t )
{
char *ptr = s; /* pointer to the string s */
while( *s++ = *t++ ) /* copy every character looping every time */
; /* null statement */
return ptr; /* return pointer to a string */
}
>>i saw this code in a particular book.....
what an awful algorithm to put in a book! I thought books were supposed to teach the language not how to obfuscate it. I think you should trash-can that book and get a different one.
>>i saw this code in a particular book.....
what an awful algorithm to put in a book! I thought books were supposed to teach the language not how to obfuscate it. I think you should trash-can that book and get a different one.
Then I would have to trash every book in C that I own.
It is amazing that I haven't found one that it doesn't use gets() or
fflush( stdin ). Sad but true.
>It is amazing that I haven't found one that it doesn't use gets() or fflush( stdin ).
That is amazing. Clearly you're not looking very hard, or your sources just plain suck.
>Clearly you're not looking very hard,
That depends of your definition of looking hard. I can tell you I own three very popular C programming book, and I have checked out at one point of another every C programming book in my local library.
Every sigle one for beginners, it has that kind of coding.
> or your sources just plain suck.
That they suck I know now.
Then I would have to trash every book in C that I own.
It is amazing that I haven't found one that it doesn't use gets() or
fflush( stdin ). Sad but true.
can you please tell me what is the problem with gets() and fflush(stdin)...
actually i thought gets() is very useful when we want to input data which has a space in it.....
thank you very much s.o.s
i was able to understand the problem with gets() but the fflush(stdin) was not clear i.e.couldn't be understood by me as i'm a beginner..... can you please explain the problems with fflush a little simpler.....
>can you please explain the problems with fflush a little simpler.....
The bottom line is this. As a beginner in many sources you are taught
to use fflush( stdin ) to clear the stdin buffer of any left characters that some functions like scanf() or getchar() leave behind. The problem is that fflush() was not ment for that, even when many compilers support it, and it will work with those compilers, still is not
a C standard which means you are playing with luck when you use it.
Making your code not portable.
> Making your code not portable.
AFAIK, the code is portable, the behavior is undefined. Though it might work for you on each run, the same can't be said about it on another machine, compiler or architecture.
>the code is portable, the behavior is undefined.
I suspect my grasp of terminology is not correct. May I ask a question?.
I know that fflush( stdin ) is undefined. However I thought that behavior underfined ment that the compiler doesn't know what to do, therefore it would not compile. If it doesn't compile, how could be the code portable?.
The bottom line is this. As a beginner in many sources you are taught
to use fflush( stdin ) to clear the stdin buffer of any left characters that some functions like scanf() or getchar() leave behind. The problem is that fflush() was not ment for that, even when many compilers support it, and it will work with those compilers, still is not
if fflush(stdin) was not meant for clearing the characters left by scanf() of getchar() then what is it actually meant for.... where is it used and can you please explain it with a sample code where it is used....
> However I thought that behavior underfined ment that the compiler
> doesn't know what to do, therefore it would not compile.
You are getting confused between the two of them. Using clrscr() is what constitutues non-portability since it is available only on Borland Compilers and is not a part of the language standard. In other words, change in the architecture, compiler or OS might result in the code not being able to compile.
Undefined behaviour is when people say '..but it works for me'. Returning an address of the local variable and using it is what constitutes undefined behaviour since the memory no longer belongs to the programmer. If you write such code, you are completely at the mercy of the runtime if it decides to use up the memory which was used by your local variable.
int fflush(FILE* stream); Flushes stream stream and returns zero on success or EOF on error. Effect undefined for input stream. fflush(NULL) flushes all output streams.
> where is it used and can you please explain it with a sample code
> where it is used
Output in C is normally buffered, which means that the output is not written character by character but in chunks. It might so happen that a printf statement you wrote never got printed since the code after it caused a segmentation fault. In that case you can force the output to be printed and the output streams be flushed using the fflush function. Read this.
>>i saw this code in a particular book.....
what an awful algorithm to put in a book! I thought books were supposed to teach the language not how to obfuscate it. I think you should trash-can that book and get a different one.
Unless the book is this :)
How Not To Program In C++
In which case just read it carefully.. :D
I don't like the explanation you've received for "undefined behavior". What this means is the C Standard has not defined the operation, and what it is supposed to do. Therefore, any given compiler can do what they want. For fflush(stdin) , the compiler designers can write the compiler to:
1) do nothing because the command is undefined
2) do the logical thing the command implies
3) do something they think it should do, which might be logical to them but not to us
4) do anything else they want the command to do, completely unrelated to logic.
the compiler designers can write the compiler to:
1) do nothing because the command is undefined
2) do the logical thing the command implies
3) do something they think it should do, which might be logical to them but not to us
4) do anything else they want the command to do, completely unrelated to logic.
Doesn't this sum up to...
Though it might work for you on each run, the same can't be said about it on another machine, compiler or architecture.
>Doesn't this sum up to...
The same can't be said about other runs either. Option #1 could result in all kinds of intermittent and unpredictable behavior.
> However I thought that behaviour undefined ment that the compiler
> doesn't know what to do, therefore it would not compile.
You are getting confused between the two of them.
Good that I asked. Now I can see how bad it is. It's at run time that the behaviour is manifested, and it is unpredictable.
I am starting to appreciate a little more Salem's signature:
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
an assignment statement return the vale of leftmost operator.
so a=b returns value of *a.
Nice work Samarium resurrecting a 5-year-old thread that nobody cares about any more.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.