Strcpy versus Strncpy in arrays

[Keith Thompson]

I learned both at the same time.

As it happens, I generally use ++var when I want to preincrement a
variable, and var++ when I want to postincrement it.

But that's not the whole story. And if you just want to increment a
variable, in a context where there's no difference between
preincrement and postincrement, you seem to have a strong preference
for one of them (I don't remeber which). That's what we found
confusing.

 

[Mark McIntyre]

you seem to have a strong preference
for one of them (I don't remeber which).

Not at all - I do however have a strong preference for clarity, and in
my experience, learners often have misunderstandings that can be
avoided by steering clear of potentially confusing constructs. For
instance, its often said that
if( 4 == somevariable )
is safer than
if(somevariable == 4)
because it avoids the possible mistake of the single equals. It is
however quite counterintuitive at first glance. Thus, while I do
believe the former is safer, I rarely recommend it.

That's what we found confusing.

I strongly suspect that what you found confusing was that to you,
these rules are *obvious* and self-explanatory, you couldn't
understand why anyone would find them otherwise, and therefore my
remark that the construct could confuse was itself baffling to you.

Sometimes one needs to step back from ones knowledge.

 

[Joe Wright]

Not at all - I do however have a strong preference for clarity, and in
my experience, learners often have misunderstandings that can be
avoided by steering clear of potentially confusing constructs. For
instance, its often said that
if( 4 == somevariable )
is safer than
if(somevariable == 4)
because it avoids the possible mistake of the single equals. It is
however quite counterintuitive at first glance. Thus, while I do
believe the former is safer, I rarely recommend it.




I strongly suspect that what you found confusing was that to you,
these rules are *obvious* and self-explanatory, you couldn't
understand why anyone would find them otherwise, and therefore my
remark that the construct could confuse was itself baffling to you.

Sometimes one needs to step back from ones knowledge.

I write C as I say it. 'If var is 4' is written..

if (var == 4)

I never confuse == and = in these expressions. If I did, either the
compiler will tell me or the test results of the program will.

for (i = 0; i < N; ++i)

Again I say it "increment i" and therefore '++i'.

 

[Skarmander]

Joe Wright wrote:

I write C as I say it. 'If var is 4' is written..

if (var == 4)

I never confuse == and = in these expressions. If I did, either the
compiler will tell me or the test results of the program will.

for (i = 0; i < N; ++i)

Again I say it "increment i" and therefore '++i'.

And you never confuse ++i and i++ in these expressions, because the
compiler or the results will tell you...

Oh, and how do you pronounce "i |= 0x80", by the way? It's either going
to be a circumscription or something that's not English. I "say" this as
"i or-is oh ex eighty", but I don't assign any significance to this --
I'm just reading the symbols. If I were going from English to code, I'd
probably say "set the eighth/high/sign bit of i", depending on i.

"Increment i" does not have the unique translation "++i". Saying that
this is "the way you say it" doesn't mean anything more than "I just
prefer ++i". This "I write it as I say it" argument just muddies the
waters; it's no more or less arbitrary than anything.

The reason most of us don't write (4 == var) regardless of safety is
because it's just not written that way outside C. Open any textbook on
mathematics, sit in any class where equations are written down, and
you'll find that equalities are never written with a constant on the
left hand side and a variable on the right. That, in turn, is a result
of left-to-right writing in English, and the way equations are typically
solved. How we say it has little to do with it.

I've said "increment i" to "i = i + 1", not "i becomes equal to the old
value of i plus one" or suchlike. Of course I'd never write "increment
i" as "i = i + 1" in C, but whether I'll use ++i or i++ depends on the
expression.

If either will do, I'll use ++i, because this is what I'm used to from
(irony) C++. Of course I have no trouble reading any of these
expressions in an abstract sense, and nobody should. And if I can avoid
it, I won't try to express them in English either. English sucks for
writing programs in, though it's excellent at pseudocode.

S.

 

[Markus Becker]

Oh, and how do you pronounce "i |= 0x80", by the way? It's either going

My german 'expression' for "i |= 0x80" is "i oder-gleich Null-x-Achtzig"
which would translate to (how is "=" pronounced in english?)
"i or-assign zero-x-eighty".

to be a circumscription or something that's not English. I "say" this as
"i or-is oh ex eighty", but I don't assign any significance to this --

Ah, I was almost right.

"Increment i" does not have the unique translation "++i". Saying that
this is "the way you say it" doesn't mean anything more than "I just
prefer ++i". This "I write it as I say it" argument just muddies the
waters; it's no more or less arbitrary than anything.

It depends on the perspective.

I've said "increment i" to "i = i + 1", not "i becomes equal to the old
value of i plus one" or suchlike. Of course I'd never write "increment
i" as "i = i + 1" in C, but whether I'll use ++i or i++ depends on the
expression.

Sure it should. There's quite a difference between "a[++i] = 42" and
"a[i++] = 42". Obviously not in terms of "i", but in terms of "a[]".

But you all know that.

Markus

 

[Skarmander]

My german 'expression' for "i |= 0x80" is "i oder-gleich Null-x-Achtzig"
which would translate to (how is "=" pronounced in english?)
"i or-assign zero-x-eighty".


Ah, I was almost right.

Make no mistake, "assign" is actually better than "is" or "gleich",
because it's *not* equality. But we're used to this by now. The horror
of languages that use := or similar for assignment! Think of all the
wasted keystrokes!

S.

 

[Old Wolf]

I write C as I say it. 'If var is 4' is written..

if (var == 4)

How do you write:
p is a pointer to function taking an int
and returning a pointer to void
?

 

[Joe Wright]

How do you write:
p is a pointer to function taking an int
and returning a pointer to void
?

Can I call you by your first name? Old? Maybe..

void *(*p)(int);

Close? What was the Wolf's point?

My original quip was that 'if (4 == var)' is counter intuitive and is
not used here.

 

[Dave Thompson]

Mark McIntyre wrote:

'again' was declared as a char. another global

So %s, which will (normally) store _at least_ 1 data character plus a
null terminator character, is UB. Use %c, and perhaps " %c" to skip
leading whitespace. Better yet, don't use scanf at all: FAQs 12.12-20
at usual places and http://www.eskimo.com/~scs/C-faq/top.html

But if it _were_ a string, then just substituting again == "Y" is
wrong in a different way; FAQ 8.2, or use again[0] == 'Y'.

- David.Thompson1 at worldnet.att.net

 

[Mabden]

Joe Wright wrote:

I have started using the "if (NO_ERROR == result)" syntax even tho I am
thoroughly anal in my code (at least, people tell me I'm a "complete
asshole", so I guess they mean my code is good...)

But in a for() loop, you want to have the idea that i will be plus-one
in the next loop, so i++ really states the idea better. In the case of
just incrementing a variable, I use "++j;" because I read it as
"increment j" as opposed to "j++;" which I read as "do nothing, then
increment j" which seems silly.

for (theRecord = Nothing; theRecord < Gold; theRecord++)
++sales;

Oh, and how do you pronounce "i |= 0x80"

Set high bit of i.

I'm just reading the symbols. If I were going from English to code, I'd
probably say "set the eighth/high/sign bit of i", depending on i.

Sixteenth bit, I'm sure you meant to say...

"Increment i" does not have the unique translation "++i". Saying that
this is "the way you say it" doesn't mean anything more than "I just
prefer ++i". This "I write it as I say it" argument just muddies the
waters; it's no more or less arbitrary than anything.

Agreed. But I like it. "It's only Rock-n-Roll, but I like it..."

The reason most of us don't write (4 == var) regardless of safety is
because it's just not written that way outside C. Open any textbook on
mathematics, sit in any class where equations are written down, and
you'll find that equalities are never written with a constant on the
left hand side and a variable on the right. That, in turn, is a result
of left-to-right writing in English, and the way equations are typically
solved. How we say it has little to do with it.

But it IS a Good Idea. I have begun to do it, and I find it really isn't
the completely inane construct I thought it was. Of course, it scans
better when the constants are #define'd. It's not:
if (4 == ever)...

it's more like:
if (FILE_LOCKED == result) file_locked (fptr);
if (FILE_PROTECTED == result) file_prot (fptr);

So you see, the info important to the programmer is right up front, AND
the compiler will balk at an error. It's a two-fer. Worth embracing.
Think on it.

I've said "increment i" to "i = i + 1", not "i becomes equal to the old
value of i plus one" or suchlike. Of course I'd never write "increment
i" as "i = i + 1" in C, but whether I'll use ++i or i++ depends on the
expression.

If either will do, I'll use ++i, because this is what I'm used to from
(irony) C++.

Double-plus good.

Of course I have no trouble reading any of these
expressions in an abstract sense, and nobody should.

Nobody should read any of these expressions in an abstract sense? Maybe
you're right... ;-)

 

[Skarmander]

Set high bit of i.


Sixteenth bit, I'm sure you meant to say...

No, I did not. Eighth is correct. You could say seventh, if you start
counting from 0 (which is neat because 1 << 7 == 0x80). "Sixteen is
right out".

You're thinking of sixteen-bit integers and their "high bits", aren't you?

But it IS a Good Idea. I have begun to do it, and I find it really isn't
the completely inane construct I thought it was. Of course, it scans
better when the constants are #define'd. It's not:
if (4 == ever)...

it's more like:
if (FILE_LOCKED == result) file_locked (fptr);
if (FILE_PROTECTED == result) file_prot (fptr);

So you see, the info important to the programmer is right up front, AND
the compiler will balk at an error. It's a two-fer. Worth embracing.
Think on it.

Hmm. This particular case study is not so convincing, given:

switch (result) {
case FILE_LOCKED: file_locked(fptr); break;
case FILE_PROTECTED: file_prot(fptr); break;
default: /* there probably ought to be something here */
}

This is one of those arguable things, you know. What info is important
to the programmer? That "result" is tested? That the symbolic constant
FILE_LOCKED means that the, eh, file is locked? Well, arguably both.
Whether you write this one way or the other is insignificant. As long as
it fits on a line.

Compare:

int main(int argc, char* argv);

function main(argc: integer, argv: array of string): integer;

Look at the clarity of that last one: first the identifier, then the
type. What does the programmer care more about, eh? This language could
be easier to learn and read!

Maybe. But when you've learned it, does it matter? No. It's easy enough
to adapt to either.

The only argument that really matters is that for (constant == variable)
the compiler will definitely catch the mistake of writing = instead of
==; the rest is stylistic quabbles which can go on forever without
reaching any sort of consensus.

The benefit of having a guaranteed error (instead of just a warning,
which many compilers will emit) just doesn't do it for me. I'm not going
to suddenly write all my comparisons differently in C because the
language has a gotcha I'm well aware of. If it works for you, great.

Nobody should read any of these expressions in an abstract sense? Maybe
you're right... ;-)

Now I'm pretty sure the grammar doesn't allow for that meaning...

S.

 

[Michael Wojcik]

(how is "=" pronounced in english?)

Like "-", but doubled.

Seriously, it depends on the speaker, of course. I rarely say it
aloud; when I do, I usually say "equals", even when it's being used
for assignment. If I needed to describe C source code orally and
precisely - if I were giving a lecture to nonexperts, perhaps - I
would probably say "gets" (an elision of "gets the value" or "gets
the value of"). With "gets", the LHS of the expression can serve
as the grammatical subject of the clause ("x gets y" for "x = y"),
which is not the case with verbs like "assign".

--
Michael Wojcik (e-mail address removed)

Art is our chief means of breaking bread with the dead ... but the social
and political history of Europe would be exactly the same if Dante and
Shakespeare and Mozart had never lived. -- W. H. Auden

 

[Jordan Abel]

But in a for() loop, you want to have the idea that i will be plus-one
in the next loop, so i++ really states the idea better. In the case of
just incrementing a variable, I use "++j;" because I read it as
"increment j" as opposed to "j++;" which I read as "do nothing, then
increment j" which seems silly.

Eh? That doesn't make sense.

 

[Netocrat]

Eh? That doesn't make sense.

Mabden probably meant "do something unnecessary" rather than "do nothing":

The "post" in post-increment implies that something is occurring first -
the storage of the original value for later use - whereas with
pre-increment there is no need to store a value.

In a void expression, there's nothing to do later with the stored value,
so there's no point in storing it in the first place.

His comment on for-loops as a special case mirrors Mark McIntyre's
comments which seem pretty reasonable. Since the increment occurs at the
end of each loop body, it's clearest for the increment operator to also
follow (occur at the end of) the variable.