Ted Bullock writes:
> I've been curious about this for a long time; Would using
> const uint16_t or uint32_t instead of proprocessor defines also make
> sense anyway if the purpose is to stop the compiler from being
> mysterious with implicit data types? I've never seen a compelling reason
> to u
On 2022-01-21 8:40 a.m., Alexander Bluhm wrote:
>>> There is no best, minimalistic and most consistent solution.
>>
>> I have always considered numberU as being the same type of thing as
>> using 'u_int' instead of 'int' for a variable, it is idiomatic C
>> to force all considerations into signed.
> Sounds like a call for the huge U change.
Since none of these #define seem to be used by .S files, go for it. We
don't really want to bring Mach's U() macro back.
On Thu, Jan 20, 2022 at 06:36:36PM -0700, Theo de Raadt wrote:
> > Alternatives are:
> > - put U to every TF_ TCP flag
> > - put U to all TF_TMR_ timer flags
> > - put U to TF_TMR_REXMT retransmit timer flag
> > - cast TF_TIMER to unsigned (what I did)
> > - cast to unsigned in the TCP_TIMER_ARM, T
Alexander Bluhm wrote:
> On Thu, Jan 20, 2022 at 07:02:43PM +, Miod Vallat wrote:
> > > An unsinged TF_TIMER does not create that problem.
> >
> > Why don't you simply append an U suffix to TF_TMR_REXMT?
>
> There are a lot of TF_ flags. Ususally we dont put an U to hex
> flags. The only
On Thu, Jan 20, 2022 at 07:02:43PM +, Miod Vallat wrote:
> > An unsinged TF_TIMER does not create that problem.
>
> Why don't you simply append an U suffix to TF_TMR_REXMT?
There are a lot of TF_ flags. Ususally we dont put an U to hex
flags. The only one that is used for shifting is TF_TMR
> An unsinged TF_TIMER does not create that problem.
Why don't you simply append an U suffix to TF_TMR_REXMT?
Hi,
TCP timers also shift undefined values.
kubsan: netinet/tcp_input.c:1027:4: shift: left shift of 67108864
by 5 places cannot be represented in type 'int'
The problem is hidden behind a bunch of macros:
TCP_SETUP_ACK(tp, tiflags, m);
#define TCP_SETUP_ACK(tp, tiflags
