Restricted unsigned integer range would have been better?

[Keith Thompson]

Really the answer depends on your librsries. C without a library
isn't much higher-level than assembly language. It's portable, it has
support for floating point, structuers, strings, and pointer
management, and it does your subroutine bookkeeping for you. But
that's only a thin layer on top of assembler.

[...]

I don't consider it a thin layer. The big difference is that assembly
language programs specify CPU instructions, while C programs specify
behavior.

That is a lame post.

Try being less rude.

"behavior"? Assembly instructions do not cause
behavior?

Yes, assembly instructions cause behavior. More precisely, assembly
instructions specify machine code instructions, which cause behavior.

What was wrong with my definition that had in it that C abstracts
the CPU instructions?

What definition is that? What term were you defining?

C does so only in the same sense that all programming languages above
the level of assembly do so.

 

[Ansel]

[...]
Really the answer depends on your librsries. C without a library
isn't much higher-level than assembly language. It's portable, it
has support for floating point, structuers, strings, and pointer
management, and it does your subroutine bookkeeping for you. But
that's only a thin layer on top of assembler.
[...]

I don't consider it a thin layer. The big difference is that
assembly language programs specify CPU instructions, while C
programs specify behavior.

That is a lame post.

Try being less rude.

And pander to your institution? Ain't gonna happen.

Yes, assembly instructions cause behavior. More precisely,

And you are "keen" on being "more precise". Because you think that is a
winning thing. "checkmate", right?

assembly
instructions specify machine code instructions, which cause behavior.

You did not have to spout out loud your reflection.

What definition is that? What term were you defining?

What is not obvious to you? I don't want to interact with you more than I
have to. I said: "C abstracts the 'CPU level'". Don't dare try to take me
back to the 1960's, cuz I may get mad.

C does so only in the same sense that all programming languages above
the level of assembly do so.

"hello". Didn't I say that the dividing line between "high" and "low" level
was exactly that?

 

[Keith Thompson]

And pander to your institution? Ain't gonna happen.

Try harder.

[snip]

 

[Ansel]

And pander to your institution? Ain't gonna happen.

Try harder.

[snip]

I don't need to do that. I just remember. You are out of the picture too.
Been for a long time.

 

[Kenny McCormack]

That is a lame post.

[/QUOTE]

Every Kiki post is lame. That's what makes them so much fun to read.

Every time I point this out, in one form or another, you can hear a giant
balloon being popped. Whoosh!!!

--
Modern Christian: Someone who can take time out from
complaining about "welfare mothers popping out babies we
have to feed" to complain about welfare mothers getting
abortions that PREVENT more babies to be raised at public
expense.

 

[Keith Thompson]

Keith Thompson wrote:
That is a lame post.

Try being less rude.

And pander to your institution? Ain't gonna happen.

Try harder.

[snip]

I don't need to do that. I just remember. You are out of the picture too.
Been for a long time.

I have no idea what you're talking about. And I no longer care.

*plonk*

 

[Kenny McCormack]

I don't need to do that. I just remember. You are out of the picture too.
Been for a long time.

I have no idea what you're talking about. And I no longer care.[/QUOTE]

You do know.

And, you cared enough to post this.

*plonk*

And enough to do that stupidest of all Usenet moves: announcing a plonk.

You are soooooo predictable, Kiki.

--
Religion is regarded by the common people as true,
by the wise as foolish,
and by the rulers as useful.

(Seneca the Younger, 65 AD)

 

[Ansel]

Keith Thompson wrote:
[...]
That is a lame post.

Try being less rude.

And pander to your institution? Ain't gonna happen.

Try harder.

[snip]

I don't need to do that. I just remember. You are out of the picture
too. Been for a long time.

I have no idea what you're talking about. And I no longer care.

*plonk*

"Anonymous Coward".

 

[Ansel]

I have no idea what you're talking about. And I no longer care.

You do know.
[/QUOTE]

Yes he does.

And, you cared enough to post this.

He did do that. He likes "poker" when the odds are stacked in his favor.
Else he folds. Game on.

And enough to do that stupidest of all Usenet moves: announcing a
plonk.

You are soooooo predictable, Kiki.

And I do hate boring. But apparently I don't get out enough, for y'all
wankers wanna "go throw the football around" or some such lame ass wanker
thing. "Enginerds" for sure.

 

[Ansel]

Every Kiki post is lame. That's what makes them so much fun to read.
[/QUOTE]

As if you were in some other category than he.

 

[Öö Tiib]

If C's unsigned integer types were designed so that their maximum value was
the same as the absolute value of the same width signed integer type's
minimum value, wouldn't that automagically elimintate a bunch of erroneous
code and simplify programming in C?

Yes.

'unsigned char' would be from 0 to 127. Rest of the 128 bit combinations
would be erroneous values.

'signed char' would be from -127 to 127. -128 would be erroneous value.

I would love those. Totally compatible with each other. Also i like
embedded error state.

The only problem that I see with the proposal is that the unsigned
integer types are so often used for screwing around with big
sets of bytes of unknown origin for making hashes, signatures and
encrypted versions. So the old types should be still available.

 

[Philip Lantz]

[..snip..snip..]

5. while (*s != '\0')
n = n * 10 + (*s - '0');

If n is of type int and also not negative,
then you could write without having to use parentheses
n = n * 10 - '0' + *s;
with no possibility of overflow.

Is there some reason you wouldn't write

n = *s-'0' + n*10; /* or add more spacing, if preferred */

?

Yes. It's the same reason I wouldn't write
while ('\0' != *s)
-- it doesn't correspond to the way I think of the operation. That
applies to pete's suggestion, too, by the way.

I wasn't even thinking of overflow when I wrote that; I put in the
parentheses to make it abundantly clear to the reader what the statement
is doing.

 

[Philip Lantz]

Philip Lantz wrote:
[..snip..snip..]

5. while (*s != '\0')
n = n * 10 + (*s - '0');

If n is of type int and also not negative,
then you could write without having to use parentheses
n = n * 10 - '0' + *s;
with no possibility of overflow.

Is there some reason you wouldn't write

n = *s-'0' + n*10; /* or add more spacing, if preferred */

?

Not any good reason.

I have an aesthetic preference
for writing the more strongly associated arithmetic operators first.

I think aesthetics *is* a good reason for writing code a certain way.
Too bad everyone doesn't agree with *my* aesthetic sense. But even
when it differs, it's still way better than code written by those who
have no aesthetic sense at all.

 

[Philip Lantz]

pete writes:
Philip Lantz wrote:
[..snip..snip..]

5. while (*s != '\0')
n = n * 10 + (*s - '0');

If n is of type int and also not negative,
then you could write without having to use parentheses
n = n * 10 - '0' + *s;
with no possibility of overflow.

Is there some reason you wouldn't write

n = *s-'0' + n*10; /* or add more spacing, if preferred */

?

Not any good reason.

I have an aesthetic preference
for writing the more strongly associated arithmetic operators first.

I think aesthetics *is* a good reason for writing code a certain way.
Too bad everyone doesn't agree with *my* aesthetic sense. But even
when it differs, it's still way better than code written by those who
have no aesthetic sense at all.

Oh, oops, I just realized someone might think I was talking about Tim
when I wrote this. I wasn't! Just a general comment on the applicability
of aesthetics to coding.

 

[Tim Rentsch]

pete writes:
Philip Lantz wrote:
[..snip..snip..]

5. while (*s != '\0')
n = n * 10 + (*s - '0');

If n is of type int and also not negative,
then you could write without having to use parentheses
n = n * 10 - '0' + *s;
with no possibility of overflow.

Is there some reason you wouldn't write

n = *s-'0' + n*10; /* or add more spacing, if preferred */

?

Not any good reason.

I have an aesthetic preference
for writing the more strongly associated arithmetic operators first.

I think aesthetics *is* a good reason for writing code a certain way.
[snip elaboration]

Sure, but not the only one. In writing, for example, it is my
preference not to split an infinitive. Sometimes, though, it's
awkward to just blindly follow that rule. In the particular
case here (ie, in assigning to n), IMO there is very little
difference aesthetically between the two writings, and the
second one even might be a little easier to digest when reading
it. Partly I was curious how much of the choice was an actual
conscious process and how much was doing things a particular way
just because that's the way the author is used to doing them.

 

[Tim Rentsch]

Tim Rentsch wrote:
pete writes:
Philip Lantz wrote:
[..snip..snip..]

5. while (*s != '\0')
n = n * 10 + (*s - '0');

If n is of type int and also not negative,
then you could write without having to use parentheses
n = n * 10 - '0' + *s;
with no possibility of overflow.

Is there some reason you wouldn't write

n = *s-'0' + n*10; /* or add more spacing, if preferred */

?


Not any good reason.

I have an aesthetic preference
for writing the more strongly associated arithmetic operators first.

I think aesthetics *is* a good reason for writing code a certain way.
Too bad everyone doesn't agree with *my* aesthetic sense. But even
when it differs, it's still way better than code written by those who
have no aesthetic sense at all.

Oh, oops, I just realized someone might think I was talking about Tim
when I wrote this.

Certainly I was not given that impression.

I wasn't! Just a general comment on the applicability
of aesthetics to coding.

The key point, I think, is that different people have different
aesthetic judgments, and also have different weights for how
important the different factors are. Oh, maybe I would add
another one, namely, sometimes people will write things one
way rather than another just because that's how they're used
to writing it. That tendency can also be dangerous, as Dijkstra
has discussed in his writings.

 

[Tim Rentsch]

Philip Lantz wrote:
[..snip..snip..]

5. while (*s != '\0')
n = n * 10 + (*s - '0');

If n is of type int and also not negative,
then you could write without having to use parentheses
n = n * 10 - '0' + *s;
with no possibility of overflow.

Is there some reason you wouldn't write

n = *s-'0' + n*10; /* or add more spacing, if preferred */

?

Yes. It's the same reason I wouldn't write
while ('\0' != *s)
-- it doesn't correspond to the way I think of the operation. That
applies to pete's suggestion, too, by the way. [snip elaboration]

But there's an important difference between the two cases,
namely, in the second one there is no other reason to choose the
alternate formulation over the original, whereas in the first
there are. I'm not trying to argue that either formulation (ie,
of the assignment to n) is compelling necessarily, only that
there are weights on both sides of the scale.

 

[Philip Lantz]

Tim Rentsch wrote:
pete writes:
Philip Lantz wrote:
[..snip..snip..]

5. while (*s != '\0')
n = n * 10 + (*s - '0');

If n is of type int and also not negative,
then you could write without having to use parentheses
n = n * 10 - '0' + *s;
with no possibility of overflow.

Is there some reason you wouldn't write

n = *s-'0' + n*10; /* or add more spacing, if preferred */

?


Not any good reason.

I have an aesthetic preference
for writing the more strongly associated arithmetic operators first.

I think aesthetics *is* a good reason for writing code a certain way.
[snip elaboration]

Sure, but not the only one. In writing, for example, it is my
preference not to split an infinitive. Sometimes, though, it's
awkward to just blindly follow that rule. In the particular
case here (ie, in assigning to n), IMO there is very little
difference aesthetically between the two writings, and the
second one even might be a little easier to digest when reading
it. Partly I was curious how much of the choice was an actual
conscious process and how much was doing things a particular way
just because that's the way the author is used to doing them.

It was conscious, because I had to consider whether to add the
parentheses. In my usual work environment, they wouldn't matter, so I
would very likely leave them out. In this newsgroup, little omissions
like that can get you attacked without mercy. So I did think about
whether to put in the parentheses, and that caused me to carefully
consider the whole expression. I stand by my choice, although I do
recognize that, as you said, different people weigh the factors
differently.

However, I honestly don't see the factors that cause you you prefer your
formulation, or why you said (in another post in this thread) that
there's no reason to choose
while ('\0' != *s)
over
while (*s != '\0')
(some people think there is, as I'm sure you know, but I don't), but you
said that there are reasons other than aesthetics to choose
n = *s-'0' + n*10;
over
n = n * 10 + (*s - '0');
(Or did I misunderstand that?)

 

[Tim Rentsch]

pete wrote:
Tim Rentsch wrote:
pete writes:
Philip Lantz wrote:
[..snip..snip..]

5. while (*s != '\0')
n = n * 10 + (*s - '0');

If n is of type int and also not negative,
then you could write without having to use parentheses
n = n * 10 - '0' + *s;
with no possibility of overflow.

Is there some reason you wouldn't write

n = *s-'0' + n*10; /* or add more spacing, if preferred */

?


Not any good reason.

I have an aesthetic preference
for writing the more strongly associated arithmetic operators first.

I think aesthetics *is* a good reason for writing code a certain way.
[snip elaboration]

Sure, but not the only one. In writing, for example, it is my
preference not to split an infinitive. Sometimes, though, it's
awkward to just blindly follow that rule. In the particular
case here (ie, in assigning to n), IMO there is very little
difference aesthetically between the two writings, and the
second one even might be a little easier to digest when reading
it. Partly I was curious how much of the choice was an actual
conscious process and how much was doing things a particular way
just because that's the way the author is used to doing them.

It was conscious, because I had to consider whether to add the
parentheses. In my usual work environment, they wouldn't
matter, so I would very likely leave them out. In this
newsgroup, little omissions like that can get you attacked
without mercy. So I did think about whether to put in the
parentheses, and that caused me to carefully consider the whole
expression.

Sorry, I wasn't clear. What I was (and am) curious about is
the choice between putting the multiplication term first or
second. Were both of those among the alternatives you
considered? (And, unimportant side issue: how about 10*n
instead of n*10?)

I stand by my choice, although I do recognize that, as you
said, different people weigh the factors differently.

At least as interesting as what choice was made is what factors
were considered. Your comment about the (putative) reaction in
the work environment, for example, isn't one I would have thought
of right off the bat.

However, I honestly don't see the factors that cause you you
prefer your formulation,

I mentioned one in the posting. Did you not see that? And are
there really no other possible factors that you could think of?

or why you said (in another post in this thread) that
there's no reason to choose
while ('\0' != *s)
over
while (*s != '\0')
(some people think there is, as I'm sure you know, but I
don't),

Not exactly. I have seen reasons stated for preferring

if(0==*s) // or some other constant besides 0

over

if(*s==0)

but I don't remember that reasoning being extended to the '!='
operator. It is of course possible to make an indirect argument
for the '!=' case, based on the proposed argument for the '=='
case, but I don't remember it (either the case or the indirect
argument) being discussed. So I still don't know of any direct
reason to prefer 0 != *s to *s != 0.

but you
said that there are reasons other than aesthetics to choose
n = *s-'0' + n*10;
over
n = n * 10 + (*s - '0');
(Or did I misunderstand that?)

What I said was the writing with the '*' done second might be
easier to digest; because that formulation doesn't have (or
need) parentheses, they don't have to be scanned, and no mental
effort is required for why they might be necessary, unlike the
formulation that does have parentheses. Surely you can imagine
other plausible motivations (eg, related to workplace reactions)
for distinguishing the two, besides just aesthetic concerns --
yes?

If I may be philosophical for a moment, IME reactions on style
issues (considering this case purely a style issue, which of
course it isn't, at least not purely) tend to fall into one of
two camps, namely: one, style choices are purely a matter of
preference, just follow whatever the local customs are; and two,
there are definite reasons for preferring one style over another,
and the preferred style should be followed without exception. I
believe neither of these camps is right. In many cases there is
no reason to prefer strongly one style over another, and when
that holds consistency with local custom should dominate. In
other cases there are good and compelling reasons for preferring
one style over another, and in those cases it is important to set
or influence local custom to go in the right direction. And
finally, it's almost never true that following a single style
choice in every circumstance, and without any alternative or
exceptions, is the best course of action. When advocating a
particular style choice (for a class of situations, but one
particular choice to apply to those situations), it's important
to discuss the limits or possible exceptional circumstances when
an alternate choice might be better. But that's kind of a
digression from the topic here, so please excuse my indulgence.

 

[glen herrmannsfeldt]

(snip)
(snip)

Sorry, I wasn't clear. What I was (and am) curious about is
the choice between putting the multiplication term first or
second. Were both of those among the alternatives you
considered? (And, unimportant side issue: how about 10*n
instead of n*10?)

Usual math notation for polynomials puts the higher powers on
the left, and the coefficient to the left of the variable.

At least as interesting as what choice was made is what factors
were considered. Your comment about the (putative) reaction in
the work environment, for example, isn't one I would have thought
of right off the bat.
(snip)

Not exactly. I have seen reasons stated for preferring

if(0==*s) // or some other constant besides 0

if(*s==0)

Not that I never make mistakes, but I don't especially
like the (0==*s) form.

but I don't remember that reasoning being extended to the '!='
operator. It is of course possible to make an indirect argument
for the '!=' case, based on the proposed argument for the '=='
case, but I don't remember it (either the case or the indirect
argument) being discussed. So I still don't know of any direct
reason to prefer 0 != *s to *s != 0.

Well, supposedly the (0==*s) form is to guard against accidentally
writing (0=*s) which will generate a compiler error.

Seems to me that when one meant (0!=*s) one could still accidentally
write (0=*s). Then again, there are a very large number of ways one
can miswrite an expression such that the compiler doesn't detect the
error.

What I said was the writing with the '*' done second might be
easier to digest; because that formulation doesn't have (or
need) parentheses, they don't have to be scanned, and no mental
effort is required for why they might be necessary, unlike the
formulation that does have parentheses. Surely you can imagine
other plausible motivations (eg, related to workplace reactions)
for distinguishing the two, besides just aesthetic concerns --
yes?

As I wrote above, normal math notation for polynomials puts the
higher powers on the left. Assuming I dind't have to worry about
overflow, I would probably write n * 10 + *s - '0', though
the form (*s - '0') emphasizes the conversion.

If I did need to worry about overflow, then it likely requires
more tests to avoid, possibly with the multiply and add on
separate statements.

If I may be philosophical for a moment, IME reactions on style
issues (considering this case purely a style issue, which of
course it isn't, at least not purely) tend to fall into one of
two camps, namely: one, style choices are purely a matter of
preference, just follow whatever the local customs are; and two,
there are definite reasons for preferring one style over another,
and the preferred style should be followed without exception.

Yes. And often the preferred style isn't the most natural or
most readable.

I believe neither of these camps is right. In many cases there
is no reason to prefer strongly one style over another, and when
that holds consistency with local custom should dominate. In
other cases there are good and compelling reasons for preferring
one style over another, and in those cases it is important to set
or influence local custom to go in the right direction. And
finally, it's almost never true that following a single style
choice in every circumstance, and without any alternative or
exceptions, is the best course of action. When advocating a
particular style choice (for a class of situations, but one
particular choice to apply to those situations), it's important
to discuss the limits or possible exceptional circumstances when
an alternate choice might be better. But that's kind of a
digression from the topic here, so please excuse my indulgence.

-- glen