Thanks for the info. What I'll probably do is file a bug and reply to this
thread and the other one when I do.
On Thu, Feb 25, 2016, 2:50 PM Joseph Myers wrote:
>
> On Wed, 24 Feb 2016, Wink Saville wrote:
>
> > Further more things like printing of "big" bit fields such as
> > unsigned long long
On Wed, 24 Feb 2016, Wink Saville wrote:
> Further more things like printing of "big" bit fields such as
> unsigned long long int b:33 doesn't issue any warnings with -Wall on clang
Of course, printing such a bit-field with %llu etc. isn't fully portable
even with the C++ semantics for bit-field
On Wed, Feb 24, 2016 at 3:38 PM, Joseph Myers wrote:
> On Wed, 24 Feb 2016, Wink Saville wrote:
>
>> > (c) nothing defines semantics of conversion of out-of-range values to
>> > bit-fields other than treating the width as part of the type (or in the
>> > case of _Bool bit-fields, having the specia
On Wed, 24 Feb 2016, Wink Saville wrote:
> > (c) nothing defines semantics of conversion of out-of-range values to
> > bit-fields other than treating the width as part of the type (or in the
> > case of _Bool bit-fields, having the special wording to make it explicit
> > that those have the semant
See comment on (c) below
On Wed, Feb 24, 2016 at 1:53 PM Joseph Myers wrote:
>
> On Wed, 24 Feb 2016, Martin Sebor wrote:
>
> > > That can be avoided simply by using unary + in the controlling expression
> > > of _Generic (just as using unary + will avoid an error from sizeof, if you
> > > want t
On Wed, 24 Feb 2016, Martin Sebor wrote:
> > That can be avoided simply by using unary + in the controlling expression
> > of _Generic (just as using unary + will avoid an error from sizeof, if you
> > want to be able to apply that to expressions that might be bit-fields) -
> > or any of the other
$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc z.c
struct S { unsigned i: 31; } s;
int i = _Generic (s.i, unsigned: 1);
z.c:2:19: error: ‘_Generic’ selector of type ‘unsigned int:31’ is not
compatible with any association
Joseph,
Thanks for the unary + suggestion.
It definitely makes sense that the bit field length must be known for
handling things like assignments, but it doesn't have to be part of
the type signature.
Martin,
I've updated bug 65471: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471
I create
On Mon, 22 Feb 2016, Martin Sebor wrote:
> for the C standard not to support it. (The problem is simply that
> wording that specifies the feature was poorly chosen and GCC seems
> to follow it a bit too strictly, and to the detriment of usability.)
The wording for bit-fields, although unclear in
On 02/21/2016 06:44 PM, Wink Saville wrote:
I've tried you hack, but it doesn't work with "long bit fields". Also,
I've run into another problem. Instead of using unsigned char for
the bit field I changed it to a long unsigned int:33 and now I can't
print it without a warning.
That's unfortunat
On Mon, 22 Feb 2016, Wink Saville wrote:
> I understand "long" bit fields are in ISO, but its a gcc extension so
> it would seem it should play nice with as much of the language as
> possible.
>
> It seems the root of the problem here is the length encoding
> in the type, why does gcc do that, do
I'm sorry I meant:
I understand "long" bit lengths are NOT in ISO, "
On Mon, Feb 22, 2016 at 4:06 PM, Wink Saville wrote:
> I understand "long" bit fields are in ISO, but its a gcc extension so
> it would seem it should play nice with as much of the language as
> possible.
>
> It seems the
I understand "long" bit fields are in ISO, but its a gcc extension so
it would seem it should play nice with as much of the language as
possible.
It seems the root of the problem here is the length encoding
in the type, why does gcc do that, does the standard
require it?
On Mon, Feb 22, 2016 at 3
On Mon, 22 Feb 2016, Wink Saville wrote:
> What about printing of "long" bit fields? I wonder if there should be an
> option which indicates that bit field types should not include their length.
"long" bit-fields aren't even guaranteed by ISO C to be supported at all;
portable code must avoid th
I wonder if ISO C really ought to have a new Constraint "The controlling
expression of a generic selection shall not be an expression that
designates a bit-field member." (so requiring a diagnostic), much like
such expressions being disallowed in sizeof, to reflect the special nature
of bit-fie
I've tried you hack, but it doesn't work with "long bit fields". Also,
I've run into another problem. Instead of using unsigned char for
the bit field I changed it to a long unsigned int:33 and now I can't
print it without a warning.
Here is my Makefile:
CC = gcc
O = 3
X = c
STD = c11
CFLAGS = -
On Fri, 19 Feb 2016, Wink Saville wrote:
> And I've tried to use _Generic to print the type of a bit field but
> the compiler fails with:
Indeed, bit-field types cannot match any type name, only default. The
only conversions applied to the controlling expression are those involved
in lvalue to
On 02/19/2016 11:25 AM, Wink Saville wrote:
I'm using gcc 5.3.0:
$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
I'm using gcc 5.3.0:
$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And I've tried to use _Generic to print th
19 matches
Mail list logo
