Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #23761

Re: Comparing Arbitrary-Precision Integers

From Eric Sosman <esosman@ieee-dot-org.invalid>
Newsgroups comp.lang.c
Subject Re: Comparing Arbitrary-Precision Integers
Date 2012-07-26 17:01 -0400
Organization A noiseless patient Spider
Message-ID <jusb73$76f$1@dont-email.me> (permalink)
References <sj8318pmtqrjdlotfttuqji8mqndf8odms@4ax.com>

Show all headers | View raw


On 7/26/2012 4:06 PM, David T. Ashley wrote:
> Hi,
>
> I'm using a 2's complement machine (and I'm comfortable baking this
> assumption into the code).  I've implemented a large number of
> functions on signed integers that are longer than the machine
> supports.
>
> Does the code below for comparison look correct?

     Looks plausible.

> typedef union
> {
>     UNSIGNED32_T uw[3];
>     SIGNED32_T   sw[3];
> } APP_BIGINT_S96_T;

     You may need to be vigilant about the type-punning here.
I think you're all right as long as you deal in pointers to the
union type itself, but it'd be a good idea to avoid passing
around pointers to the uw and sw members independently.  Some
compiler might reason "Storing through this `unsigned int*'
cannot affect the value I've already loaded from this other
`signed int*' ..."  (Disclaimer: Aliasing rules are slipperier
than my grasp is firm, and I may be worrying about nothing.  But
if I were you I'd put a Bar-certified language lawyer on retainer.)

> //REENTRANCY
> //   This function has not been evaluated for re-entrancy or thread
> safety.  This function is
> //   designed to be called from background (non-ISR) software only.

     There cannot be reentrancy problems, since the function cannot
be re-entered.  I see no concurrency issues in the function itself;
you need only ensure that the bigints aren't being changed while
you're in the act of inspecting them.  The ISR restriction seems
irrelevant.

> //UNIT TEST HISTORY
> //   20120713:  Not yet unit tested.

     I trust you've remedied this in the last two weeks ...

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Comparing Arbitrary-Precision Integers David T. Ashley <dashley@gmail.com> - 2012-07-26 16:06 -0400
  Re: Comparing Arbitrary-Precision Integers Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-26 17:01 -0400
    Re: Comparing Arbitrary-Precision Integers Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:49 -0700
  Re: Comparing Arbitrary-Precision Integers "BartC" <bc@freeuk.com> - 2012-07-26 22:20 +0100
    Re: Comparing Arbitrary-Precision Integers Ike Naar <ike@sverige.freeshell.org> - 2012-07-26 21:46 +0000
      Re: Comparing Arbitrary-Precision Integers "BartC" <bc@freeuk.com> - 2012-07-26 23:14 +0100
        Re: Comparing Arbitrary-Precision Integers David T. Ashley <dashley@gmail.com> - 2012-07-27 17:55 -0400
  Re: Comparing Arbitrary-Precision Integers Michael Angelo Ravera <maravera@prodigy.net> - 2012-07-26 17:51 -0700
  Re: Comparing Arbitrary-Precision Integers bartek szurgot <basz@no.spam> - 2012-07-27 08:53 +0200
    Re: Comparing Arbitrary-Precision Integers David T. Ashley <dashley@gmail.com> - 2012-07-27 18:02 -0400
      Re: Comparing Arbitrary-Precision Integers Ike Naar <ike@iceland.freeshell.org> - 2012-07-27 22:23 +0000
        Re: Comparing Arbitrary-Precision Integers Keith Thompson <kst-u@mib.org> - 2012-07-27 16:53 -0700
          Re: Comparing Arbitrary-Precision Integers David T. Ashley <dashley@gmail.com> - 2012-07-27 21:25 -0400
      Re: Comparing Arbitrary-Precision Integers Noob <root@127.0.0.1> - 2012-07-30 14:29 +0200
        Re: Comparing Arbitrary-Precision Integers David T. Ashley <dashley@gmail.com> - 2012-07-30 09:28 -0400
  Re: Comparing Arbitrary-Precision Integers "io_x" <a@b.c.invalid> - 2012-07-27 20:46 +0200

csiph-web