«

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
d

Eric Sosman <> writes:

> 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, [snip elaboration]

The types signed/unsigned int are always allowed to alias, as are
all other corresponding pairs of signed/unsigned integer types.

However, it would be worth checking to see if gcc's 'strict-aliasing'
option may violate this rule (and possibly generate non-conforming
code as a result).