Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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
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