Re: compare a large number of variables

"Mark B" <sober@xxxxxxxxxxxx> writes:

> Wow, I thought this part of the thread died a week ago with my last post...
> took you long enough to respond
> (btw: was out friday and don't work weekends which is why it took me a few
> days to respond :)

Yes, real life keeps interfering with the more important
activity of keeping up on comp.lang.c. :)

I'm going to try to trim this down to just the relevant
portions...


> "Tim Rentsch" <txr@xxxxxxxxxxxxxxxxxxx> wrote in message
> news:kfnpss0luzs.fsf@xxxxxxxxxxxxxxxxxxxxxx
> > "Mark" <sober@xxxxxxxxxxxx> writes:
> >
> >> "Tim Rentsch" <txr@xxxxxxxxxxxxxxxxxxx> wrote in message
> >> news:kfnzmrd8xpz.fsf@xxxxxxxxxxxxxxxxxxxxxx
> >> > "Mark" <sober@xxxxxxxxxxxx> writes:

> Though I am not a pedant so I do sometimes respond
> to what I perceive people to 'mean' rather than what they actually
> do say...

When you do that it's usually a good idea to make it
explicit, eg, "what I think you mean is ..." and then
proceed from there. Otherwise readers will probably
think you've misunderstood, or worse.


> > The comment I think you're referring to is one you made in
> > an earlier post that isn't quoted above; namely:
> >
> > > >> if(a-b|b-c|c-d|d-e /* ... */)
> > > >> puts("mismatched");
> > > >> else
> > > >> puts("pick one... they're all the same");
> > >
> > > > All zero? Overflow?
> > >
> > > Overflow is not possible, stare at it for a while and
> > > see if you can figure out why ;)
> >
> > As written this statement is wrong. The expression in the
> > 'if' certainly can overflow. It also can result in
> > undefined behavior even if the subtraction operators don't
> > result in overflow.
>
> I must be missing something... how can it result in
> undefined behavior with no overflow?

unsigned char a = 3, b = 5, c = 8;

if(a-b|b-c) ...

The arguments of 'a-b' and 'b-c' are promoted (assuming
UCHAR_MAX < INT_MAX) to 'int', and the results therefore
are negative, with no overflow. Doing a bitwise OR of
negative operands means undefined behavior; 6.5 p4.


> > On the other hand, several postings did
> > declare variables of *signed* integer type, including
> > variables that participated in the comparison (as might be
> > represented by a,b,c, etc, in the 'if' above).
>
> Check again, maybe else-thread, but not in this particular
> branch.

Posting by Jack Klein, directly responding to the OP;
not on the path to the root posting by the OP, but it
being a direct response and a few days earlier it seems
reasonable to include.

Posting by Eric Sosman, directly responding to the OP; on
the path to the root from this post. Any posting on the
path to the root seems like it should count as part of
"this branch".

Both of these should be easy to find with google; for
some reason I can't get a citation URL out of google
right now.


> > If you meant to say, "as long as the variables are of some
> > unsigned integer type, overflow can't happen", that may be
> > true, but not really very relevant, since there still is
> > the possibility of undefined behavior.
>
> How?

See above.


> > If you meant to say, "*if* the operands are all of type
> > 'unsigned int', then no overflow or undefined behavior can
> > occur", that's true, but then why didn't you just say that?
>
> I thought I did... by posting what I thought to be the relevent
> section from the (draft) standard.

You may have meant to imply it, but you didn't state it.
It's usually good to remember that people reading what
you post can't read your mind.


> None of the earlier posts specified ANY type.
> Follow this thread back to the OP and you'll see that.

They did, as I detailed above; one was on the path to
the OP.


> >> > If what is
> >> > being talked about is overflow -- which I think is a reasonable
> >> > assumption considering the context -- then the relevant portion
> >> > of the cited H.2.2 is only that about signed integer types.
> >> But we have been dealing with bit operands the entire time,
> >> so considering the context you should assume we are
> >> dealing with unsigned integer types, no? I have been... which again
> >> is why I earlier stated that 'overflow is not possible'.
> >
> > You may imagine that the operands were "bit operands", but
> > there is nothing in what you wrote to indicate that;
>
> <q>No, it also states that unsigned integer types DO behave a certain
> way.</q>

The quoted comment is a statement about types. It isn't
a statement about operands. It's important to say what
you mean, directly and explicitly. This really shouldn't
be so hard to understand -- people respond to what you
actually write, not to the thoughts that are in your head.


> > and,
> > to the contrary in earlier postings when variables were
> > declared as 'int' rather than 'unsigned int'.
>
> You keep referring to this earlier post in which the
> variables were declared... maybe my newsreader missed a
> few messages... whose post, and when? Maybe I'll be able
> to find it using google, because I certainly didn't get it here.

After my first statement that there were, you could have
used google to find the postings, and that would have
avoided the confusion. I used google to review the
thread before responding to your earlier comments, to
make sure I hadn't missed something.


> >> > In my document [ISO/IEC 9899:1999 (E)], 3.18 is a definition of
> >> > the ceiling function.
> >> Impossible, there is no such function in the C language. [snip]
> >
> > It's not only possible, if you get a copy of the C standard
> > document mentioned above, you'll see that it's true.
>
> Am I the only poster in clc using the draft?

No; but I do think you're one of the few to make unequivocal
statements about what's in the official version when you
are using just the draft version.


> I'm suprised to find that they've added a function they don't
> mention in the final draft... maybe I should spend the $18
> to see what else I'm missing :)

There are at least a few significant differences. I found
it worth my while to get a copy of the official version.


> > Incidentally, note that I said 3.18 is a definition of the
> > ceiling function, not the 'ceiling' function.
>
> Yes, and I stated that I assumed you were referring to the
> 'ceil functions' - isn't that still the appropriate terminology?

You did state that, which is why I made a point of making a
clarifying statement. Dave Thompson also explained this in
a separate posting (thank you Dave).


> It is according to the final draft, maybe they changed it between
> then and the final version :-) Does a word search on 'ceiling'
> return anything in the final version of the standard? If so, I may
> have to spend the $18 - otherwise the final draft may still do
> me just fine.

I do recommend getting one. Also, one other recommendation -
try to develop the habit of reading what is written and not
what you presume is meant. Besides getting on better in
the newsgroup, you'll find this habit helpful in reading
the standard document itself.
.

Relevant Pages

  • Re: Paul what happended to the draft?
    ... Now, I know I was not posting for a while so this may have been covered, ... but a recent story on CNN made me think about it. ... way to get somebody to be goose stepping to you. ... Draft them and make ...
    (alt.smokers.cigars)
  • Re: Judging Theo and the FO: Draft Analysis 2003-2005
    ... myself (and perhaps Mr. Bismo) posting more about the minor league ... in the draft due to concerns about their mechanics and durability. ... the team drafting needs be judged on that as well. ...
    (alt.sports.baseball.bos-redsox)
  • Re: Mysterious angle brackets [Was: convincing the authorities: definition of "espresso"]
    ... when posting via Google Groups. ... I still have the draft of the post, ... with> to prevent mail reading programs from interpreting it as a sender address. ...
    (alt.usage.english)
  • Re: Buggy "clock scan" (8.5.0)
    ... [A complimentary Cc of this posting was sent to ... The fact of whether it is an overflow or not does ... country (or state/province, or a county, or a municipality). ...
    (comp.lang.tcl)
  • Fortran 2008 public comment e-mail address
    ... The e-mail address for public comments on the Fortran 2008 draft given ... in an earlier posting does not show correctly when viewed using the ... browser I use. ...
    (comp.lang.fortran)