strcpy - my implementation

[arnuld]

You still haven't fixed the const on the src parameter.

OMG! , I just forgot :-\

 

[Richard]

arnuld said: [...]

That whole discussion leaves me wondering whether:

char arrc[100] = {0};

is same as:

char arrc[100];
memset(arrc, '\0', 100);

or whether latter is more expansive than former ?

Since you're initialising an array of integers (for chars are integers),
they do the same thing. The first version does it in fewer lines of code.
If the type were non-integer (e.g. pointer, or floating point, or struct
or union of any kind), the two versions would not be equivalent and the
memset version would simply be wrong.

A struct, union, or array whose only non-composite sub-members are of
integer type [*] can safely be initialized with memset, setting the
whole thing to all-bits-zero. It's only unsafe if some of the
sub-members are of floating-point or pointer type.

(Note that it's still not entirely equivalent, since memset will zero
any padding bytes, and {0} won't necessarily do so. Also, {0} might,
on some exotic implementation, use a representation of 0 other than
all-bits-zero -- I think.

Few! I thought it was only me that didn't understand this stuff anymore
after reading posts in c.l.c!

 

[Richard]

I didn't say the effect differed. I said the code generated
differed, before optimization. It has to, because one uses the
value of c, and the other converts that to 0 or 1 before testing.

I dont think I ever heard something SO wrong before in a technical news
group. Congratulations Chuck. You have proven me wrong on one thing -
you can indeed get more ridiculous.

 

[CBFalconer]

.... snip ...


No, it doesn't have to differ. I suppose a compiler could generate
painfully naive code with some options, but there's no reason for
the value to be converted to 0 or 1. Even in the case where I
found a difference, there was no such conversion.

In any case, by definition the statement "if (c) { ... }" compares
the value of c to 0. That comparison is done by the equivalent of
"c != 0", which yields a value of 0 or 1. There's just as much
basis (i.e., practically none) for assuming that "if (c)" will
convert the result to 0 or 1 as for assuming that "if (c != '\0')"
will do so.

Well, we have different ideas of what optimization does and where
it starts. To me, the compiler parses "if (" and then compiles a
statement, requiring a ')' termination char. If the statement is a
comparison, it must do the conversion to 0 or 1 because those are
the only values that a comparison can yield. When it finds the ')'
termination char it evaluates that statement and makes the decision
based on a zero or non-zero value. Optimization can go over the
code generated above as it wishes to remove unnecessary code.

 

[Keith Thompson]

Well, we have different ideas of what optimization does and where
it starts. To me, the compiler parses "if (" and then compiles a
statement, requiring a ')' termination char. If the statement is a
comparison, it must do the conversion to 0 or 1 because those are
the only values that a comparison can yield. When it finds the ')'
termination char it evaluates that statement and makes the decision
based on a zero or non-zero value. Optimization can go over the
code generated above as it wishes to remove unnecessary code.

You mean expression, not statement.

Given:

if (expr) stmt;

the "stmt;" part is executed "if the expression compares unequal to
0". So by your reasoning, if the expression is "c" (the value of an
object of type char), then c must be compared to 0 by the equivalent
of "c != 0", yielding a value of 0 or 1, which determines the
subsequent control flow. If the expression is "c != '\0'", then that
comparison is done, yielding 0 or 1, and then that result is compared
to 0, again yielding 0 or 1.

Typically these trivial comparisons aren't eliminated by a separate
optimization phase, they're just not generated in the first place.
For example, the compiler's processing of a "!=" operator might vary
depending on the context in which it appears; if it's assigned to an
object, then it has to result in a value of 0 or 1 (which may require
extra code), but if it's the top-level operator of an if or while
condition, it might just result directly in a "branch if equal"
instruction (or, more likely, the equivalent in some intermediate
code).