Re: [Hamlib-developer] What am I missing?

[<gm...@bt...>]

C still allows compilers with 16-bit ints. IIRC the Arduino IDE still uses 16-bit ints. I know hamlib would never fit in an Arduino, but I think using the fixed width types such as (u)int32_t is a sensible idea where the width IS important or the supported values can be outwith the minimum limitation of the C int type.

The space rocket Ariane V failed its test launch because of an integer overflow.

73 Phil GM3ZZA


________________________________
From: Greg Troxel <gd...@le...>
Sent: 27 July 2025 12:09 AM
To: Nate Bargmann <n0...@n0...>
Cc: ham...@li... <ham...@li...>
Subject: Re: [Hamlib-developer] What am I missing?

Nate Bargmann <n0...@n0...> writes:

> * On 2025 26 Jul 09:52 -0500, George Baltz wrote:
>> I'm wondering if this is why shortfreq_t is still a long.  Signed 16 bits
>> might be too short (repeater offset) but 32 bits would work.
>>
>> Would it be possible to change shortfreq_t to int32 for 5.0?
>
> I think so as we're communicating with the advancement of the major
> number that API changes are made and ABI is broken.
>
> Any such values that appear to be limited should probably be evaluated
> for 5.0.

And implicitly, if there's any concern about the actual size of the
type, C99(?) fixed-width types like int32_t are prepared.

I am surprised though about 16-bit ints.  Perhaps that's a Windows thing
semi-recently.  Unix on the PDP-11 (V6, V7 and 2.8-2.11 BSD) had 16 bit
ints and 32 bit longs.   I am pretty sure the Vax had 32 bit int right
away.  And that's mid 80s with PDP-11s fading by mid 90s.




_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer