svn commit: r305636 - head/sys/ddb

[Pedro Giffuni]

Hello;


On 09/09/2016 00:27, Bruce Evans wrote:
> On Fri, 9 Sep 2016, Justin Hibbits wrote:
>
>> Log:
>>  Correct the type of db_cmd_loop_done.
>>
>>  On big endian hardware that uses 1 byte bool a type mismatch of bool 
>> vs int will
>>  cause the least signifcant byte of db_cmd_loop_done to be set, but 
>> the MSB to be
>>  read, and read as 0.  This causes ddb to stay in an infinite loop.
>
> Hrmph.  I objected to converting ddb to bool.
>
True. Changing to bool also uncovered some missing ANSIfication though.

>> Modified: head/sys/ddb/db_command.c
>> ============================================================================== 
>>
>> --- head/sys/ddb/db_command.c    Fri Sep  9 02:02:13 2016 (r305635)
>> +++ head/sys/ddb/db_command.c    Fri Sep  9 04:16:53 2016 (r305636)
>> @@ -59,7 +59,7 @@ __FBSDID("$FreeBSD$");
>> /*
>>  * Exported global variables
>>  */
>> -bool        db_cmd_loop_done;
>> +int        db_cmd_loop_done;
>> db_addr_t    db_dot;
>> db_addr_t    db_last_addr;
>> db_addr_t    db_prev;
>
> It used to use boolean_t, but was misinitialized with 0 and 1 instead of
> FALSE and TRUE.  Then it used bool, but was misinitialized with 0 and 1
> instead of false and true.  Now it is initialized with matching types
> for the literals, but its type regressed 2 steps.
>
> But what was the problem?  (int)1 (or any nonzero value) is converted
> to (bool)true on assigment.  The final value is always 1 if converted
> back to an int, and probably also when viewed as bits in memory. When
> bool has 8 bits big endian, this means that it has bits 0b00000001
> where you can't really know the bit order within a byte.
>
Changing to bool unhides type mismatches. It may cause pain now but on 
the long run it may be better ... I think.

It's a shame this will still hit 11.0 though.

Pedro.