«

Hi

Am 23.06.2012 05:42, schrieb Tim Rentsch:
> Jens Gustedt <> writes:
>
>> with C11's _Generic you may do that, provided your implementation
>> hasn't extended integer types that are narrower than int,
>>
>> you can do something horrible like
>>
>> _Generic(var,
>> default: use_the_previous_method(var),
>>
>> char: (CHAR_MAX < UCHAR_MAX),
>> char const: (CHAR_MAX < UCHAR_MAX),
>> [snip remainder]
>
> In most cases I expect this approach will work fine, but unfortunately
> it doesn't always,

It did some more experiments with this and actually found that the
handling of qualified types is not very well designed with this new
_Generic tool. In the case it was asked here (for a variable, i.e an
lvalue) it seems consistent, but for rvalues it is completely
underspecified.

I'll post a question comp.std.c about this

> specifically for bitfields.

the signedness of bitfields is really a special case oddity. What
should _Generic trigger, here. The declared type or the effective
type?

A bitfield that is declared with just "int" could (implementation
defined) well be unsigned in nature. To the extreme on a system with
32 bit wide "int", a bit field with specification "int a:32" could be
unsigned.

> Btw, the many redundant parentheses are, well, redundant.

but not superficial

coding styles vary, as you probably know

Jens

Jens Gustedt <> writes:

> Hi
>
> Am 23.06.2012 05:42, schrieb Tim Rentsch:
>> Jens Gustedt <> writes:
>>
>>> with C11's _Generic you may do that, provided your implementation
>>> hasn't extended integer types that are narrower than int,
>>>
>>> you can do something horrible like
>>>
>>> _Generic(var,
>>> default: use_the_previous_method(var),
>>>
>>> char: (CHAR_MAX < UCHAR_MAX),
>>> char const: (CHAR_MAX < UCHAR_MAX),
>>> [snip remainder]
>>
>> In most cases I expect this approach will work fine, but unfortunately
>> it doesn't always,
>
> It did some more experiments with this and actually found that the
> handling of qualified types is not very well designed with this new
> _Generic tool. In the case it was asked here (for a variable, i.e an
> lvalue) it seems consistent, but for rvalues it is completely
> underspecified.
>
> I'll post a question comp.std.c about this

Okay, I'll look over at that.


>> specifically for bitfields.
>
> the signedness of bitfields is really a special case oddity. What
> should _Generic trigger, here. The declared type or the effective
> type?

Good question! I wonder if the Standard says, or if a DR should
be filed for that?

> A bitfield that is declared with just "int" could (implementation
> defined) well be unsigned in nature. To the extreme on a system with
> 32 bit wide "int", a bit field with specification "int a:32" could be
> unsigned.

Not just could be but would be, on a system where 'int' means
unsigned int for bitfields.

My point about bitfields (which was a bit off the mark for the
particular context here, but oh well) is that using _Generic for
bitfields gives misleading results as regards their behavior
under integer promotion rules (ie, a bitfield declared as
'unsigned x:3' will show up as unsigned int but will promote to
an int). More confusingly, a bitfield is an lvalue but cannot
have its address taken. It would be nice if these distinctions
could be handled under _Generic, but alas they cannot.


>> Btw, the many redundant parentheses are, well, redundant.
>
> but not superficial
>
> coding styles vary, as you probably know

My comment was only about the redundancy, not about style.
However, on the issue of style, IME style rules that promote
using redundant parentheses almost always do more harm than
good. I don't see any added value in using parentheses as
they were in the example above. Conversely, I do see a big
negative, in that people unfamiliar with the new _Generic
construct might come away with the mistaken impression that
those parentheses are required. The reason for my comment
was to correct any such mistaken conclusions.

On 6/15/2012 10:02 AM, Noob wrote:
> James Kuyper wrote:
>
>> John Reye wrote:
>>
>>> Get Jens Gustedt's fantastic P99_SIGNED macro here:
>>> http://p99.gforge.inria.fr/p99-html/...eb39ccac28ebd8...
>>
>> That link doesn't work for me.
>
> Google "helpfully" truncates URLs. Neat, uh?

Somewhat helpful for Google Groups users. Not helpful
for the rest of Usenet, since they don't convert their
own messages containing URLs to NNTP format correctly
for long URLs.