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

[George B. <geo...@gm...>]

How about [PC|MS]-DOS? That would have almost faded away by the time 
hamlib started, but maybe it was considered as a use for retired systems.

It may be time to reconsider some other data types with this major 
version update, and some major H/W changes since it was last done.


On 7/26/25 7:09 PM, Greg Troxel wrote:
> 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