a[i] = a[j]... Dangerous?

[s0suk3]

I'm a bit unclear whether a statement such as 'a[i] = a[j];' causes
undefined behavior or some other abnormalities. A statement such as
'a[i] = a[i++];' would definitely cause problems because of the double
use and side effect of 'i'. But in the former case, will the double
use of the array 'a' cause problems? Or will the right operand
('a[j]') of the assignment be evaluated first and then safely assigned
to the right operand ('a[i]')?

Thanks

[Ben Bacarisse]

"Robbie Hatley" <se************ **@for.my.email .addresswrites:

"Willem" <wi****@stack.n lwrote:

>... he [Robbie Hatley] should (IMO) keep the library function
call that he's replacing in a comment....

Misquote. I never replaced any library function call. I wrote
the code in question from scratch, electing not to use any
library function calls.

I did not read it as you have edited it. The exchange was:

| ) The professional programmer won't tolerate any increase in syntactic
| ) complexity for the sake of avoiding the use of a standard library function.
| ) The exception would be when he is optimizing.
|
| In which case he should (IMO) keep the library function call that he's
| replacing in a comment.

To me, the "he" refers to "the professional programmer" not to you in
person as your edit of the quote seems to suggest. The discussion had
drifted into a general exchange about what to do ("keep the original")
in the (now hypothetical) case where one *has* replaced a library
call. At any rate, when I read the message you replied to, I did not
read it a referring to your code anymore.

--
Ben.

[Mark McIntyre]

Robbie Hatley wrote:

"Kaz Kylheku" <kk******@gmail .comwrote:

>All you are doing is burdening the reader with more
responsibility .

No. Library functions require looking-up syntax and
semantics, whereas for loops and pointers are part of the
basic language.

Ok, but in the case of the standard library, the programmer should be
familiar enough with the type of function you refer to, for its syntax
to be as familiar as the basic language.

So in those rare cases where the hand-
written version is simpler (clearer to the reader) than
a library function call, I tend to write it by hand.

But note that this comes at a potential cost of erroneous results &
slower performance, harder maintenance and more possibility of failing
to catch a tricky case.

As a junior maintenance droid some time ago I was once tasked with
cleaning up some code that had been 'optimised' by a self-styled
uberprogrammer. This consisted of removing overly complex use of the
language, rerolling gratuitously unrolled loops, replacing hand-crafted
functions with normal library functions etc.

The reason I had to do this was that a) hardly anyone on the team could
understand the code and b) it was generating wrong answers in obscure
but customer-relevant cases. A side-effect of my work was that it ran
faster.

>... the reader has to analyze the code carefully; or else
such a little detail can easily be missed...

Always true when reading code, REGARDLESS of whether library
functions are used or not.

But surely you must agree that
memmove(a,b);
is quicker and clearer to read than 100 lines of hand-crafted code.

>... This is a 10 node abstract syntax tree....

I think you're over-technicalizing a simple thing.
I just go by what WORKS, and what is CLEAR, "abstract
syntax trees" not withstanding.

Just to warn you, OVER capitalising is often regarded as the start of a
slippery slope!

>The expanded algorithm does /not/ just state that meaning;
the meaning emerges from the relationship of the individual
steps of the algorithm, as it unfolds in time.

Some don't grok C. C'est la vie.

That's not Kaz's point. He's discussing the algo.

If my boss hires someone
who can't understand for loops, that's his loss, not mine.

Well yes and no - all programmers should strive to write understandable
code, as not everyone is as smart and clueful as themselves. And as a
'boss' myself I take the view that my staff should care about whether
they're being productive for the /company/ - which includes writing code
that is maintainable by less expert than themselves. Overcomplex and
oversmart code isn't productive...

>The professional programmer won't tolerate any increase in
syntactic complexity for the sake of avoiding the use of
a standard library function. The exception would be when
he is optimizing.

A mostly-true platitude. But like all platitudes, it has
it's limits of applicability, and if over-relied-on, can
be as harmful as it is helpful.

Your response is also a platitude, of course ! :-)
--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[jacob navia]

Mark McIntyre wrote:
[big snip]

>
But surely you must agree that
memmove(a,b);
is quicker and clearer to read than 100 lines of hand-crafted code.

It is quicker and clearer but also completely wrong.

The prototype for memmove is:
void * memmove(void *, const void *, size_t);

You missed the size_t argument.

Should I deduce that writing library functions is as error prone
as inlining the code?

:-)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Robbie Hatley said:

>
Richard Heathfield wrote:

>Robbie Hatley said:

>
// YES:
for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1];

...we have to think more carefully about whether the code
is right....

Typo. Scroll up a couple of messages, and you'll see it
started out like this:

for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+100];

Dunno how the two zeros got cut out.

Neither do I.

>

// NO:
memmove(blat, &blat[100], 700 * sizeof *blat);

But this doesn't do the same thing!

It does, if you put the zeros back.

But not if you don't. I don't recall seeing the zeros at all.

>

>Use this instead:

memmove(blat, blat + 1, 700 * sizeof *blat);

No, a correct version would be:

memmove(blat, blat + 100, 700 * sizeof *blat);

Now that you mention the zeros, yes. But my code was a correct rewrite of
the code I could see.

>
But I MUCH prefer:

for ( i = 0 ; i < 700 ; ++i ) blat[i] = blat[i+100];

Because it says EXACTLY what it does, and EXACTLY how
it does it, in 52 characters, 14 of which are whitespace.

memmove(blat, blat + 100, 700 * sizeof *blat);

says EXACTLY what it does, and explains EXACTLY why it isn't important how
it does it, in 46 characters, 7 of which are whitespace.

Whereas, memmove is an opaque "black box".

Its semantics are clearly described in the Standard.

>The C language doesn't define a strcomp function.

Typo. strcmp. Don't be silly; you can intuit that.

Getting it right is a good habit to get into. Assuming that other people
will interpret your typos in the way you intended is a bad habit to get
into, and one that can cost millions of LCUs.

// This one, i don't even know if it CAN be done by hand,
// and even if it could, the home-spun version probably
// wouldn't be portable:
printf("Number of employees = %d\n", NumEmp);

It can, and it would be. But that doesn't mean it would
be *wise*.

Of course it's not wise. I never said it was.

Right. Neither is rolling your own memmove.

In fact,
I said the opposite. There are times and places for
library functions. Printing things is one of those.

Actually, there are times when you can't use the standard routines (because
they don't give the desired effect). For example, if you want to pop a
dialog box onto the screen with your message centred over an OK button,
printf probably isn't going to cut it. So I/O is one of those places where
you very often /do/ need to roll your own. But your specific example,
where you ask for a portable workaround, would simply be a rewriting of
printf to avoid calling printf, and that's silly.

But in my opinion, shifting some data 100 bytes to the
left is not.

Actually, shifting data around is exactly the kind of thing where you do
want to use the standard library, because it's exactly the kind of thing
that each implementor can spend hours and days and weeks and months
optimising for their target platform. Even if by some miracle you did
manage to outperform an implementor's memmove on one platform using
portable code, it's very unlikely that your speed gain would persist
across platforms.

If in doubt, use the Standard Library. If I were maintaining your stuff,
I'd spend a few minutes trying to work out why you didn't call memmove,
and then I'd rip your stuff out and put a memmove call in there. I'd also
send out an email to the rest of the project team, suggesting that they
keep half an eye out for unnecessary stdlib rewrites.

But, of course, I'm not maintaining your stuff - something for which I am
profoundly grateful. :-)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Kaz Kylheku]

On 2008-07-03, Robbie Hatley <se************ **@for.my.email .addresswrote:

Specifically, in the "for-loop vs memmove" case you quote,
the library function is more error prone, because you have to
get three different arguments correct for it to work right.

All three arguments are also present in the inline code.

>... and unproductive ...

Nonsense. If it's more clear to the reader, then it's MORE
productive, because it takes the reader less time to understand,
and REDUCES chance of errors due to reader misunderstandin g.

However, your naive reinvention of memmove doesn't have any
of the above attributes.

(Hint: the reader may be someone other than the original author.)

Don't get me wrong, I use std library functions all the time.
But if I can do the same thing with a single, simple line of

Writing it all in one line doesn't make it one line.

The way to measure code size is to look at the number of nodes
in the abstract syntax tree.

easy-to-understand home-spun code, i'll use the home-spun
instead, because it's more TRANSPARENT:

The intent of the code is to move a block of so much memory from the
source address to the destination address.

This is exactly expressed in the C language with the function call

memmove(destina tion_address, source_address, so_much).

There is no need whatsoever for this to be ``transparent'' ;
it is a well-understood, primitive operation.

Inline code is not transparent; it burdens the reader with the necessity
to understand it.

Transparency in computer science typically refers to the freedom from unwanted
interference in the communication of data, flow of control, or reference to
storage.

// YES:
for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1];

The above is incomplete, because i has to be defined somewhere:

int i; for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1];

Someone who is maintaining this code has to analyze the algorithm
to convince himself that it really is just performing a block move.

A slight modification in the code can change it so that it does
something other than a block move. It's easy for a maintainer
to miss such a change:

int i; for ( i = 0; i < 700 ; ++i ) blat[i] += blat[i+1];

The inline code contains significantly more syntax. If we transliterate
it into a parse tree notation, we get this:

((int i)
(for (= i 0) (< i 700) (++ i))
(= (blat i) (blat (+ i 1))))

This tree contains 19 nodes. If we transliterate the memmove call
to an abstract syntax tree:

memmove(blat, blat + 100, 700 * sizeof *blat);

(memmove blat (+ blat 100) (* 700 (sizeof (* blat))))

We get only 10 nodes. The inline code represents a 1.9 times bloat in raw
syntactic complexity! That doesn't even include the bloat in /semantic/
complexity, namely that the inline code encodes its meaning in an algorithm
from which the meaning emerges as the total effect of many small steps which
must be understood individually and in relation to each other as they
unfold in time, whereas the function call simply /states/ its meaning.

I save library functions for things which can NOT be easily
handled by hand-written code, such as:

// Could do this by hand, but this is MUCH easier:
if (strcomp(str1, str2)) {......}

If you really used strcmp, wouldn't you know what it's called?

And it's actually not that difficult to inline the above by hand.

// 5-node syntax tree

if (strcmp(s1, s2)) statement;

can be written:

// 16-node syntax tree

while (*s1 && *s2) if (*s1++ != *s2++) { statement; break; }

The strcmp version is more than three times smaller. So what you are saying is
that bloating up code by a factor of three is outside of your comfort zone; you
will consider the library function instead. But if the hand-written code
``only'' bloats the syntax by a factor of 1.9, then it's okay to go ahead with
it.

The professional programmer won't tolerate any code bloat caused by eschewing
the use of a suitable standard library function, except when the code is being
optimized.
** Posted from http://www.teranews.com **

[Kaz Kylheku]

On 2008-07-04, Kaz Kylheku <kk******@gmail .comwrote:

On 2008-07-03, Robbie Hatley <se************ **@for.my.email .addresswrote:

>Specifically , in the "for-loop vs memmove" case you quote,
the library function is more error prone, because you have to
get three different arguments correct for it to work right.

All three arguments are also present in the inline code.

Wow, Friday article appears out of Teranews black hole the following Wednesday!

Strangly, it's still not visible on their server!

[CBFalconer]

Kaz Kylheku wrote:

Kaz Kylheku <kk******@gmail .comwrote:

>Robbie Hatley <se************ **@for.my.email .addresswrote:

>>Specificall y, in the "for-loop vs memmove" case you quote,
the library function is more error prone, because you have to
get three different arguments correct for it to work right.

All three arguments are also present in the inline code.

Wow, Friday article appears out of Teranews black hole the
following Wednesday!

Strangly, it's still not visible on their server!

Teranews has that habit. It appears about every two weeks or so.
Then they propagate the whole schmeer after a three to five day
delay. Recently they had even more failings, so I switched to
motzarella, and all seems fine so far. When I first used Teranews
they didn't have that delay problem.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

CBFalconer wrote:

Kaz Kylheku wrote:

>Kaz Kylheku <kk******@gmail .comwrote:

>>Robbie Hatley <se************ **@for.my.email .addresswrote:

Specifically , in the "for-loop vs memmove" case you quote,
the library function is more error prone, because you have to
get three different arguments correct for it to work right.

All three arguments are also present in the inline code.

Wow, Friday article appears out of Teranews black hole the
following Wednesday!

Strangly, it's still not visible on their server!

Teranews has that habit. It appears about every two weeks or so.
Then they propagate the whole schmeer after a three to five day
delay. Recently they had even more failings, so I switched to
motzarella, and all seems fine so far. When I first used
Teranews they didn't have that delay problem.

PS: Teranews has also taken to stealing the Organization slot in
the headers. A further nuisance.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Robbie Hatley]

Richard Heathfield wrote:

memmove(blat, blat + 100, 700 * sizeof *blat);
says EXACTLY what it does,

The name "memmove" says VAGUELY what the function does (moves
something in memory), but neglects to mention many aspects, such as
the fact that the standard mandates that memmove() copies memory
contents in such as way that the source bytes are not altered before
writing them to the destination area. For this function's name to
"say EXACTLY what it does", it would need to be renamed to something
like "memory_block_c opy_with_protec ted_source".

and explains EXACTLY why it isn't important how it does it

The standard makes very specific demands on how memmove is to
behave, so "how it does it" does become important.

Whereas, memmove is an opaque "black box".

Its semantics are clearly described in the Standard.

The readership for code I write here at work consists of newbie
programmers who do not possess copies of the standard, and are
unlikely to spend time researching library functions. They're
not going to read the "clear descriptions" in the standard.
So I tend to write to their level.

... shifting data around is exactly the kind of thing where
you do want to use the standard library ... Even if by
some miracle you did manage to outperform an implementor's
memmove on one platform using portable code, it's very unlikely
that your speed gain would persist across platforms.

I never said I was attempting to write for speed. We're talking
about moving a small ammount of data, once every 20 minutes, on
a system with a 32-bit CPU running at 1-2 GHz. Many things in life
strike me as being "important" , but trying to save 200nS per each
20 minutes is NOT one of them.

But since you insist, it is quite likely that on any one platform
a simple for loop may be roughly twice as fast as the equivalent
memmove() call. Why? Because the standard insists that memmove()
copy "as if via a temporary". Depending on how it's implimented,
each byte may be copied twice:

// Copy maybe first to temporary array, then to destination:
memmove ( blat, blat + 100, 700 * sizeof *blat );

Whereas with my for loop, there is no doubt: it uses *NO* temporary:

// Copy with no temporary:
for ( i = 0 ; i < 700 ; ++i ) blat[i] = blat[i+100];

If this code had been embedded in an outer loop which ran this code
many times per second, then the for loop might be dramatically
superior to memmove, depending on how the compiler author chose to
impliment memmove.

If in doubt, use the Standard Library.

I was never "in doubt". I spent about 2 seconds considering
whether to call a standard library function, before rejecting it
unreservedly.

In general, std-lib functions often include error-checks and
safeguards which, while helpful in most situations, may be harmful
in others. So I'd say, if "in doubt", study the situation to see
if it has any specific requirements which may need special handling.
If it doesn't, and if a std-lib function is available which will
reduce code complexity and increase clarity, then I agree, call the
std-lib function.

If I were maintaining your stuff, I'd spend a few minutes trying
to work out why you didn't call memmove,

The reasons were personal-preference and audience-consideration,
not technical. You couldn't work out the reasons by inspection.

and then I'd rip your stuff out and put a memmove call in there.
I'd also send out an email to the rest of the project team,
suggesting that they keep half an eye out for unnecessary stdlib
rewrites.

You'd get an angry letter from the boss about "wasting time",
and stoney silence from your co-workers, who would only vaguely
understand your message, and would not take your advice.

But, of course, I'm not maintaining your stuff - something for
which I am profoundly grateful. :-)

It wasn't written for you. If I write something for you to
maintain, I'll write it in a style more to your liking (incl.
heavier use of library functions).

But if I'm copying 100 bytes of data from point A to point B,
I still might use a for loop, depending on the situation. :-)

--
for (i = 0; i < 700; ++i) blat[i] = blat[i+100]; /* :-P */
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[Richard Heathfield]

Robbie Hatley said:

>
Richard Heathfield wrote:

>memmove(blat , blat + 100, 700 * sizeof *blat);
says EXACTLY what it does,

The name "memmove" says VAGUELY what the function does (moves
something in memory),

Perhaps I'm too used to it, then. I think of it as being just as
descriptive as any English word. I don't have to go running to the
dictionary whenever I see the word "cat", and I don't have to go running
to the Standard every time I see the word "memmove".

but neglects to mention many aspects, such as
the fact that the standard mandates that memmove() copies memory
contents in such as way that the source bytes are not altered before
writing them to the destination area.

All of this is well-known. The English word "cat" neglects to mention many
aspects of the cat nature, such as stubbornness, ignoritude, inability (or
refusal) to understand about not jumping on the table, etc. Nevertheless,
when someone says "cat", all these connotations are immediately apparent
to me, without my having to think about it consciously. The same applies
to memmove.

<snip>

>and explains EXACTLY why it isn't important how it does it

The standard makes very specific demands on how memmove is to
behave, so "how it does it" does become important.

Not to the programmer - only to the implementor. The programmer only needs
to know that, if you're copying data that overlap, you should use memmove
rather than memcpy.

The readership for code I write here at work consists of newbie
programmers who do not possess copies of the standard, and are
unlikely to spend time researching library functions.

Scary. I just hope they're not writing anything important.

They're
not going to read the "clear descriptions" in the standard.
So I tend to write to their level.

You would do better to get them to aim for a higher level.

>... shifting data around is exactly the kind of thing where
you do want to use the standard library ... Even if by
some miracle you did manage to outperform an implementor's
memmove on one platform using portable code, it's very unlikely
that your speed gain would persist across platforms.

I never said I was attempting to write for speed.

That is about the only justification (and itself often a spurious one) that
I can think of for reinventing the standard library.

We're talking
about moving a small ammount of data, once every 20 minutes, on
a system with a 32-bit CPU running at 1-2 GHz. Many things in life
strike me as being "important" , but trying to save 200nS per each
20 minutes is NOT one of them.

Agreed. A memmove call is quicker to type, quicker to read, and generally
quicker to execute than its hand-rolled loop equivalent. The second of
these reasons is normally the most important.

>
But since you insist, it is quite likely that on any one platform
a simple for loop may be roughly twice as fast as the equivalent
memmove() call. Why? Because the standard insists that memmove()
copy "as if via a temporary". Depending on how it's implimented,
each byte may be copied twice:

Yes, it may - but you'd be hard-pressed to find a mainstream implementation
that did it that way.

>
// Copy maybe first to temporary array, then to destination:
memmove ( blat, blat + 100, 700 * sizeof *blat );

Whereas with my for loop, there is no doubt:

You would do better to trust your implementor (unless you're knowingly
using a lame implementation, in which case change it).

it uses *NO* temporary:

// Copy with no temporary:
for ( i = 0 ; i < 700 ; ++i ) blat[i] = blat[i+100];

If this code had been embedded in an outer loop which ran this code
many times per second, then the for loop might be dramatically
superior to memmove, depending on how the compiler author chose to
impliment memmove.

Since shoving stuff around in RAM is such an important job, I think you'll
find that the implementor has gone to a lot of trouble to make memmove as
efficient as he possibly can.

>

>If in doubt, use the Standard Library.

I was never "in doubt". I spent about 2 seconds considering
whether to call a standard library function, before rejecting it
unreservedly.

In general, std-lib functions often include error-checks and
safeguards which, while helpful in most situations, may be harmful
in others. So I'd say, if "in doubt", study the situation to see
if it has any specific requirements which may need special handling.
If it doesn't, and if a std-lib function is available which will
reduce code complexity and increase clarity, then I agree, call the
std-lib function.

Right - so in this case that'd be memmove.

>If I were maintaining your stuff, I'd spend a few minutes trying
to work out why you didn't call memmove,

The reasons were personal-preference and audience-consideration,
not technical. You couldn't work out the reasons by inspection.

Not all audiences will appreciate your "consideration" , though I'm sure it
was kindly meant.

>and then I'd rip your stuff out and put a memmove call in there.
I'd also send out an email to the rest of the project team,
suggesting that they keep half an eye out for unnecessary stdlib
rewrites.

You'd get an angry letter from the boss about "wasting time",

Misdirection of mail is a crime in many jurisdictions; I would feel obliged
to forward the letter to the appropriate recipient.

and stoney silence from your co-workers, who would only vaguely
understand your message, and would not take your advice.

Sturgeon did have a point, didn't he?

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999