Re: [PATCH 05/11] make predefined_type_size() more generic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12/12/2018 16:33, Luc Van Oostenryck wrote:
> On Tue, Dec 11, 2018 at 10:55:33PM +0000, Ramsay Jones wrote:
>>
>>
>> On 09/12/2018 23:43, Luc Van Oostenryck wrote:
>>> This allows to have a single function to output the
>>> size, the type, the maximal value, ...
>>> ---
>>>  lib.c | 57 ++++++++++++++++++++++++++++++++++++---------------------
>>>  1 file changed, 36 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/lib.c b/lib.c
>>> index db33e58b2..1156f6f6c 100644
>>> --- a/lib.c
>>> +++ b/lib.c
>>> @@ -1144,6 +1144,15 @@ static char **handle_switch(char *arg, char **next)
>>>  	return next;
>>>  }
>>>  
>>> +#define	PTYPE_SIZEOF	(1U << 0)
>>> +#define	PTYPE_T		(1U << 1)
>>> +#define	PTYPE_SIZEOF_T	(PTYPE_SIZEOF|PTYPE_T)
>>> +#define	PTYPE_MAX	(1U << 2)
>>> +#define	PTYPE_MIN	(1U << 3)
>>> +#define	PTYPE_TYPE	(1U << 4)
>>> +#define	PTYPE_WIDTH	(1U << 4)
>>
>> (1U << 4) used twice for _TYPE and _WIDTH.
> 
> Uh, indeed. Thanks for noticing this.
>  
>>> +	if (flags & PTYPE_MAX) {
>>> +		const char *suffix = builtin_type_suffix(type);
>>> +		predefined_max(name, suffix, bits);
>>
>> predefined_max() does not account for signed-ness of the type, so
>> that _all_ unsigned types have a _MAX value that is the same as
>> the signed variant. e.g. __UINT16_MAX__ is 0x7fff rather than 0xffff.
> 
> Indeed, when I started this series all the types were signed.
> This is fixed now. Thanks!
>  
>>> +	}
>>> +	if (flags & PTYPE_TYPE)
>>> +		predefined_type(name, type);
>>
>> The type names are not expressed the same as gcc (not a big deal), but
>> we could change the type names in the typenames[] table to match.
>> (show-parse.c, ln 222).
> 
> Yes, I know. In fact it's more or less on purpose as 'unsigned long'
> talks to me much more than 'long unsigned int'.

Heh, yes I agree with you here! (and the C standard refers to it
this was as well) :-D

> I suppose you only care about a one-to-one textual correspondance
> when testing/comparing with what GCC outputs?

Yeah, as I said, its not a big deal - I can 'translate' in my
head while looking at the meld output!

Ah, I see you have just posted another series - I will get back
to you.

ATB,
Ramsay Jones




[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux