&errno, sizeof errno

Discussion in 'C Programming' started by viza, Sep 12, 2008.

  1. viza

    viza Guest

    Hi all,
    A quick one - since errno is a lvalue, can I do:

    fread( & errno, sizeof errno, 1, fp )

    ?
    TIA
    viza
    viza, Sep 12, 2008
    #1
    1. Advertising

  2. On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    > "Jack Klein" <> wrote in message
    > news:...
    >> On Fri, 12 Sep 2008 01:22:47 GMT, viza
    >> <> wrote in comp.lang.c:
    >>> fread( & errno, sizeof errno, 1, fp )

    >>
    >> The example given in the standard for errno as a macro would work the
    >> way you want.
    >>
    >> I can't think of a macro that would expand to a modifiable lvalue and
    >> yet not work, but I'm I could if I put my mind to it, and others here
    >> almost certainly will.

    >
    > Ahh, a challange... What if an implementation did something like:
    >
    > struct {
    > __flags : 16;
    > } __errrno;
    >
    > #define errno (__errno.__flags)
    >
    > /* :) */


    If the implementation does that, I would argue that the type of errno is
    not int (even if int has 16 bits). Instead, the type is int : 16. Another
    possibility is
    extern volatile int errno;
    where I would argue the type is volatile int.

    However, consider this:

    register int errno;

    Even though user code is not permitted to define static objects with the
    keyword register, if this is a supported extension by the implementation,
    I don't think any requirements on errno have been violated if the
    implementation makes use of it.
    Harald van Dijk, Sep 12, 2008
    #2
    1. Advertising

  3. viza

    viza Guest

    On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    > "Jack Klein" <> wrote
    >> On Fri, 12 Sep 2008 01:22:47 GMT, viza
    >> <> wrote in comp.lang.c:


    >>> A quick one - since errno is a lvalue, can I do:
    >>>
    >>> fread( & errno, sizeof errno, 1, fp )


    >> "The macro errno need not be the identifier of an object. It might
    >> expand to a modifiable lvalue resulting from a function call (for
    >> example, *errno())."


    >> I can't think of a macro that would expand to a modifiable lvalue and
    >> yet not work, but I'm I could if I put my mind to it, and others here
    >> almost certainly will.

    >
    > Ahh, a challange... What if an implementation did something like:
    >
    > struct {
    > __flags : 16;
    > } __errrno;
    >
    > #define errno (__errno.__flags)


    __errno.__flags is not a "modifiable lvalue of type int".

    >> Another potential problem is that fread() is allowed, but not required,
    >> to set the underlying lvalue to any value except 0, in case of an error
    >> or just for the heck of it.


    Ok, I forgot that the implementation of fread() might write an
    intermediate error to errno even in the case of ultimate success.
    viza, Sep 12, 2008
    #3
  4. viza

    James Kuyper Guest

    Harald van Dijk wrote:
    > On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    >> "Jack Klein" <> wrote in message
    >> news:...

    ....
    >>> I can't think of a macro that would expand to a modifiable lvalue and
    >>> yet not work, but I'm I could if I put my mind to it, and others here
    >>> almost certainly will.

    >> Ahh, a challange... What if an implementation did something like:
    >>
    >> struct {
    >> __flags : 16;
    >> } __errrno;
    >>
    >> #define errno (__errno.__flags)
    >>
    >> /* :) */

    >
    > If the implementation does that, I would argue that the type of errno is
    > not int (even if int has 16 bits). Instead, the type is int : 16.


    A bit-field's width is not part of the type of the bit-field. It merely
    determines how much space that bit field takes up. See 6.3.1.1p2, which
    says:

    "The following may be used in an expression wherever an int or unsigned
    int may be used:
    ....
    — A bit-field of type _Bool, int, signed int, or unsigned int."

    If the width of a bit-field were part of it's type, the parenthesized
    part of 6.3.2.3p5 would be unnecessary: "Two structures share a common
    initial sequence if corresponding members have compatible types (and,
    for bit-fields, the same widths)".

    6.7.2p5 says "Each of the comma-separated sets designates the same type,
    except that for bit-fields, it is implementation-defined whether the
    specifier int designates the same type as signed int or the same type
    as unsigned int."

    6.7.2.1p4: "A bit-field shall have a type that is a qualified or
    unqualified version of _Bool, signed int, unsigned int, or some other
    implementation-defined type."

    In each case, the standard talks about the type of a bit field without
    while referring only to standard-defined type names, and not referring
    to the width.
    James Kuyper, Sep 12, 2008
    #4
  5. On Fri, 12 Sep 2008 21:20:28 +0000, James Kuyper wrote:
    > Harald van Dijk wrote:
    >> If the implementation does that, I would argue that the type of errno
    >> is not int (even if int has 16 bits). Instead, the type is int : 16.

    >
    > A bit-field's width is not part of the type of the bit-field. It merely
    > determines how much space that bit field takes up. [examples snipped]
    >
    > In each case, the standard talks about the type of a bit field without
    > while referring only to standard-defined type names, and not referring
    > to the width.


    It's interesting that one of the examples you gave was 6.3.1.1p2. I'll
    quote another part of it:

    "If an int can represent all values of the original type, the value is
    converted to an int; otherwise, it is converted to an unsigned int. These
    are called the integer promotions."

    Here, "the original type" does include the bit field's width. The standard
    is not consistent in treating width as part of the type.
    Harald van Dijk, Sep 12, 2008
    #5
  6. James Kuyper <> writes:
    [...]
    > A bit-field's width is not part of the type of the bit-field. It
    > merely determines how much space that bit field takes up. See
    > 6.3.1.1p2, which says:
    >
    > "The following may be used in an expression wherever an int or
    > unsigned int may be used:
    > ...
    > Ñ A bit-field of type _Bool, int, signed int, or unsigned int."

    [...]
    > 6.7.2.1p4: "A bit-field shall have a type that is a qualified or
    > unqualified version of _Bool, signed int, unsigned int, or some other
    > implementation-defined type."
    >
    > In each case, the standard talks about the type of a bit field without
    > while referring only to standard-defined type names, and not referring
    > to the width.


    Agreed. But 6.7.2.1p9 confuses matters slightly:

    A bit-field is interpreted as a signed or unsigned integer type
    consisting of the specified number of bits.

    So, apparently, given:

    struct {
    unsigned int bf:3;
    };

    bf *is* of type unsigned int (at least 16 bits), but it's *interpreted
    as* an unsigned integer type consisting of 3 bits.

    (Though the standard says it's interpreted as a type, it's actually
    interpreted as a member of that type.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 12, 2008
    #6
  7. Harald van Dijk <> writes:
    > On Fri, 12 Sep 2008 21:20:28 +0000, James Kuyper wrote:
    >> Harald van Dijk wrote:
    >>> If the implementation does that, I would argue that the type of errno
    >>> is not int (even if int has 16 bits). Instead, the type is int : 16.

    >>
    >> A bit-field's width is not part of the type of the bit-field. It merely
    >> determines how much space that bit field takes up. [examples snipped]
    >>
    >> In each case, the standard talks about the type of a bit field without
    >> while referring only to standard-defined type names, and not referring
    >> to the width.

    >
    > It's interesting that one of the examples you gave was 6.3.1.1p2. I'll
    > quote another part of it:
    >
    > "If an int can represent all values of the original type, the value is
    > converted to an int; otherwise, it is converted to an unsigned int. These
    > are called the integer promotions."
    >
    > Here, "the original type" does include the bit field's width.


    I don't believe it does.

    Here's the context (I'm quoting from n1256, which does differ from
    C99; I haven't gone back to check what the change bar refers to):

    The following may be used in an expression wherever an int or
    unsigned int may be used:

    -- An object or expression with an integer type whose integer
    conversion rank is less than or equal to the rank of int and
    unsigned int. [n1256 has a change bar here]

    -- A bit-field of type _Bool, int, signed int, or unsigned int.

    If an int can represent all values of the original type, the value
    is converted to an int; otherwise, it is converted to an unsigned
    int. These are called the _integer promotions_. All other types
    are unchanged by the integer promotions.

    As far as I can tell, given a bit field "unsigned int bf:3;", the
    "original type" of bf is unsigned int.

    This does make a difference. If the "original type" is "unsigned
    int:3", then the value would be promoted to type int; if the original
    type is unsigned int, then the value would be (trivially) promoted to
    type unsigned int. But I can't think of a case where the difference
    would be visible in the behavior of a program.

    > The standard
    > is not consistent in treating width as part of the type.


    It's not as clear as it might be, but I *think* it's consistent.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 12, 2008
    #7
  8. On Fri, 12 Sep 2008 15:32:50 -0700, Keith Thompson wrote:
    > Harald van Dijk <> writes:
    >> It's interesting that one of the examples you gave was 6.3.1.1p2. I'll
    >> quote another part of it:
    >>
    >> "If an int can represent all values of the original type, the value is
    >> converted to an int; otherwise, it is converted to an unsigned int.
    >> These are called the integer promotions."
    >>
    >> Here, "the original type" does include the bit field's width.

    >
    > I don't believe it does.
    >[...]
    > As far as I can tell, given a bit field "unsigned int bf:3;", the
    > "original type" of bf is unsigned int.


    I picked that sentence so that I could avoid a lengthy discussion in case
    of a disagreement. See DR #122. :)
    Harald van Dijk, Sep 13, 2008
    #8
  9. Harald van Dijk <> writes:
    > On Fri, 12 Sep 2008 15:32:50 -0700, Keith Thompson wrote:
    >> Harald van Dijk <> writes:
    >>> It's interesting that one of the examples you gave was 6.3.1.1p2. I'll
    >>> quote another part of it:
    >>>
    >>> "If an int can represent all values of the original type, the value is
    >>> converted to an int; otherwise, it is converted to an unsigned int.
    >>> These are called the integer promotions."
    >>>
    >>> Here, "the original type" does include the bit field's width.

    >>
    >> I don't believe it does.
    >>[...]
    >> As far as I can tell, given a bit field "unsigned int bf:3;", the
    >> "original type" of bf is unsigned int.

    >
    > I picked that sentence so that I could avoid a lengthy discussion in case
    > of a disagreement. See DR #122. :)


    But DR #122 applies to C90 (which I'm guessing is the reason for the
    smiley).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 13, 2008
    #9
  10. On Sat, 13 Sep 2008 00:56:05 -0700, Keith Thompson wrote:
    > Harald van Dijk <> writes:
    >> On Fri, 12 Sep 2008 15:32:50 -0700, Keith Thompson wrote:
    >>> Harald van Dijk <> writes:
    >>>> It's interesting that one of the examples you gave was 6.3.1.1p2.
    >>>> I'll quote another part of it:
    >>>>
    >>>> "If an int can represent all values of the original type, the value
    >>>> is
    >>>> converted to an int; otherwise, it is converted to an unsigned int.
    >>>> These are called the integer promotions."
    >>>>
    >>>> Here, "the original type" does include the bit field's width.
    >>>
    >>> I don't believe it does.
    >>>[...]
    >>> As far as I can tell, given a bit field "unsigned int bf:3;", the
    >>> "original type" of bf is unsigned int.

    >>
    >> I picked that sentence so that I could avoid a lengthy discussion in
    >> case of a disagreement. See DR #122. :)

    >
    > But DR #122 applies to C90


    Sure, but the text is unchanged between C90 and C99, so I see no reason
    for assuming there is a difference in meaning, and I am not aware of C99-
    conforming compilers following a different interpretation.

    > (which I'm guessing is the reason for the smiley).


    The smiley was because I figured it would be hard to find any other
    example more explicit than that.
    Harald van Dijk, Sep 13, 2008
    #10
  11. Harald van Dijk <> writes:
    > On Sat, 13 Sep 2008 00:56:05 -0700, Keith Thompson wrote:
    >> Harald van Dijk <> writes:
    >>> On Fri, 12 Sep 2008 15:32:50 -0700, Keith Thompson wrote:
    >>>> Harald van Dijk <> writes:
    >>>>> It's interesting that one of the examples you gave was 6.3.1.1p2.
    >>>>> I'll quote another part of it:
    >>>>>
    >>>>> "If an int can represent all values of the original type, the value
    >>>>> is
    >>>>> converted to an int; otherwise, it is converted to an unsigned int.
    >>>>> These are called the integer promotions."
    >>>>>
    >>>>> Here, "the original type" does include the bit field's width.
    >>>>
    >>>> I don't believe it does.
    >>>>[...]
    >>>> As far as I can tell, given a bit field "unsigned int bf:3;", the
    >>>> "original type" of bf is unsigned int.
    >>>
    >>> I picked that sentence so that I could avoid a lengthy discussion in
    >>> case of a disagreement. See DR #122. :)

    >>
    >> But DR #122 applies to C90

    >
    > Sure, but the text is unchanged between C90 and C99, so I see no reason
    > for assuming there is a difference in meaning, and I am not aware of C99-
    > conforming compilers following a different interpretation.
    >
    >> (which I'm guessing is the reason for the smiley).

    >
    > The smiley was because I figured it would be hard to find any other
    > example more explicit than that.


    If that was the intent, it's a pity they didn't change the wording in
    C99 to reflect that.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 13, 2008
    #11
  12. viza

    Tim Rentsch Guest

    viza <> writes:

    > On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    > > "Jack Klein" <> wrote
    > >> On Fri, 12 Sep 2008 01:22:47 GMT, viza
    > >> <> wrote in comp.lang.c:

    >
    > >>> A quick one - since errno is a lvalue, can I do:
    > >>>
    > >>> fread( & errno, sizeof errno, 1, fp )

    >
    > >> "The macro errno need not be the identifier of an object. It might
    > >> expand to a modifiable lvalue resulting from a function call (for
    > >> example, *errno())."

    >
    > >> I can't think of a macro that would expand to a modifiable lvalue and
    > >> yet not work, but I'm I could if I put my mind to it, and others here
    > >> almost certainly will.

    > >
    > > Ahh, a challange... What if an implementation did something like:
    > >
    > > struct {
    > > __flags : 16;
    > > } __errrno;
    > >
    > > #define errno (__errno.__flags)

    >
    > __errno.__flags is not a "modifiable lvalue of type int".


    If in some implementation ints are 32 bits, and if we have

    struct { int __flags : 32; } __errno;

    then how is the type of (__errno.__flags) different from int?
    Certainly (__errno.__flags) is a modifiable lvalue.

    I understand its address cannot be taken with &, but that's
    because it's a bitfield, not because of its type.
    Tim Rentsch, Sep 14, 2008
    #12
  13. viza

    Guest

    On Sep 14, 4:03 pm, Tim Rentsch <> wrote:
    > viza <> writes:
    > > On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    > > > "Jack Klein" <> wrote
    > > >> On Fri, 12 Sep 2008 01:22:47 GMT, viza
    > > >> <> wrote in comp.lang.c:

    >
    > > >>> A quick one - since errno is a lvalue, can I do:

    >
    > > >>> fread( & errno, sizeof errno, 1, fp )

    >
    > > >> "The macro errno need not be the identifier of an object. It might
    > > >> expand to a modifiable lvalue resulting from a function call (for
    > > >> example, *errno())."

    >
    > > >> I can't think of a macro that would expand to a modifiable lvalue and
    > > >> yet not work, but I'm I could if I put my mind to it, and others here
    > > >> almost certainly will.

    >
    > > > Ahh, a challange... What if an implementation did something like:

    >
    > > > struct {
    > > > __flags : 16;
    > > > } __errrno;

    >
    > > > #define errno (__errno.__flags)

    >
    > > __errno.__flags is not a "modifiable lvalue of type int".

    >
    > If in some implementation ints are 32 bits, and if we have
    >
    > struct { int __flags : 32; } __errno;
    >
    > then how is the type of (__errno.__flags) different from int?
    > Certainly (__errno.__flags) is a modifiable lvalue.
    >
    > I understand its address cannot be taken with &, but that's
    > because it's a bitfield, not because of its type.



    Another point: If its type were a bitfield int of 32 bits, then a cast
    would make sense;
    However, (int : 16) is a syntax error.
    , Sep 14, 2008
    #13
  14. viza

    Tim Rentsch Guest

    James Kuyper <> writes:

    > Harald van Dijk wrote:
    > > On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    > >> "Jack Klein" <> wrote in message
    > >> news:...

    > ...
    > >>> I can't think of a macro that would expand to a modifiable lvalue and
    > >>> yet not work, but I'm I could if I put my mind to it, and others here
    > >>> almost certainly will.
    > >> Ahh, a challange... What if an implementation did something like:
    > >>
    > >> struct {
    > >> __flags : 16;
    > >> } __errrno;
    > >>
    > >> #define errno (__errno.__flags)
    > >>
    > >> /* :) */

    > >
    > > If the implementation does that, I would argue that the type of errno is
    > > not int (even if int has 16 bits). Instead, the type is int : 16.

    >
    > A bit-field's width is not part of the type of the bit-field. It merely
    > determines how much space that bit field takes up.


    The width of a bit-field does affect its type when the
    bit-field member is used in an expression.

    struct { unsigned bf : 8; } s;
    s.bf = 0;
    printf( "s.bf - 1 < 1 == %d\n", s.bf - 1 < 1 );

    Changing '8' to the number of bits in an unsigned int
    will result in a different value.
    Tim Rentsch, Sep 14, 2008
    #14
  15. viza

    Tim Rentsch Guest

    Tim Rentsch <> writes:

    > viza <> writes:
    >
    > > On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    > > > "Jack Klein" <> wrote
    > > >> On Fri, 12 Sep 2008 01:22:47 GMT, viza
    > > >> <> wrote in comp.lang.c:

    > >
    > > >>> A quick one - since errno is a lvalue, can I do:
    > > >>>
    > > >>> fread( & errno, sizeof errno, 1, fp )

    > >
    > > >> "The macro errno need not be the identifier of an object. It might
    > > >> expand to a modifiable lvalue resulting from a function call (for
    > > >> example, *errno())."

    > >
    > > >> I can't think of a macro that would expand to a modifiable lvalue and
    > > >> yet not work, but I'm I could if I put my mind to it, and others here
    > > >> almost certainly will.
    > > >
    > > > Ahh, a challange... What if an implementation did something like:
    > > >
    > > > struct {
    > > > __flags : 16;
    > > > } __errrno;
    > > >
    > > > #define errno (__errno.__flags)

    > >
    > > __errno.__flags is not a "modifiable lvalue of type int".

    >
    > If in some implementation ints are 32 bits, and if we have
    >
    > struct { int __flags : 32; } __errno;
    >
    > then how is the type of (__errno.__flags) different from int?
    > Certainly (__errno.__flags) is a modifiable lvalue.
    >
    > I understand its address cannot be taken with &, but that's
    > because it's a bitfield, not because of its type.


    Of course, I meant to say 'signed int' rather than 'int' there...
    Tim Rentsch, Sep 14, 2008
    #15
  16. viza

    Guest

    On Sep 14, 4:20 pm, Tim Rentsch <> wrote:
    > Tim Rentsch <> writes:
    > > viza <> writes:
    > > struct { int __flags : 32; } __errno;

    >
    > > then how is the type of (__errno.__flags) different from int?
    > > Certainly (__errno.__flags) is a modifiable lvalue.

    >
    > > I understand its address cannot be taken with &, but that's
    > > because it's a bitfield, not because of its type.

    >
    > Of course, I meant to say 'signed int' rather than 'int' there...


    Why? I don't see how your article is wrong without that correction.
    , Sep 14, 2008
    #16
  17. viza

    Tim Rentsch Guest

    writes:

    > On Sep 14, 4:03 pm, Tim Rentsch <> wrote:
    > > viza <> writes:
    > > > On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    > > > > "Jack Klein" <> wrote
    > > > >> On Fri, 12 Sep 2008 01:22:47 GMT, viza
    > > > >> <> wrote in comp.lang.c:

    > >
    > > > >>> A quick one - since errno is a lvalue, can I do:

    > >
    > > > >>> fread( & errno, sizeof errno, 1, fp )

    > >
    > > > >> "The macro errno need not be the identifier of an object. It might
    > > > >> expand to a modifiable lvalue resulting from a function call (for
    > > > >> example, *errno())."

    > >
    > > > >> I can't think of a macro that would expand to a modifiable lvalue and
    > > > >> yet not work, but I'm I could if I put my mind to it, and others here
    > > > >> almost certainly will.

    > >
    > > > > Ahh, a challange... What if an implementation did something like:

    > >
    > > > > struct {
    > > > > __flags : 16;
    > > > > } __errrno;

    > >
    > > > > #define errno (__errno.__flags)

    > >
    > > > __errno.__flags is not a "modifiable lvalue of type int".

    > >
    > > If in some implementation ints are 32 bits, and if we have
    > >
    > > struct { int __flags : 32; } __errno;
    > >
    > > then how is the type of (__errno.__flags) different from int?
    > > Certainly (__errno.__flags) is a modifiable lvalue.
    > >
    > > I understand its address cannot be taken with &, but that's
    > > because it's a bitfield, not because of its type.

    >
    >
    > Another point: If its type were a bitfield int of 32 bits, then a cast
    > would make sense;
    > However, (int : 16) is a syntax error.


    You do realize don't you that this point is irrelevant to the
    question that was asked?
    Tim Rentsch, Sep 14, 2008
    #17
  18. viza

    Tim Rentsch Guest

    writes:

    > On Sep 14, 4:20 pm, Tim Rentsch <> wrote:
    > > Tim Rentsch <> writes:
    > > > viza <> writes:
    > > > struct { int __flags : 32; } __errno;

    > >
    > > > then how is the type of (__errno.__flags) different from int?
    > > > Certainly (__errno.__flags) is a modifiable lvalue.

    > >
    > > > I understand its address cannot be taken with &, but that's
    > > > because it's a bitfield, not because of its type.

    > >
    > > Of course, I meant to say 'signed int' rather than 'int' there...

    >
    > Why? I don't see how your article is wrong without that correction.


    Because in bit-fields 'int' is allowed to mean 'unsigned int'
    or 'signed int'.
    Tim Rentsch, Sep 14, 2008
    #18
  19. viza

    Guest

    On Sep 14, 5:16 pm, Tim Rentsch <> wrote:
    > writes:
    > > On Sep 14, 4:03 pm, Tim Rentsch <> wrote:
    > > > viza <> writes:
    > > > > On Thu, 11 Sep 2008 22:47:27 -0400, Scott Fluhrer wrote:
    > > > > > "Jack Klein" <> wrote
    > > > > >> On Fri, 12 Sep 2008 01:22:47 GMT, viza
    > > > > >> <> wrote in comp.lang.c:

    >
    > > > > >>> A quick one - since errno is a lvalue, can I do:

    >
    > > > > >>> fread( & errno, sizeof errno, 1, fp )

    >
    > > > > >> "The macro errno need not be the identifier of an object. It might
    > > > > >> expand to a modifiable lvalue resulting from a function call (for
    > > > > >> example, *errno())."

    >
    > > > > >> I can't think of a macro that would expand to a modifiable lvalue and
    > > > > >> yet not work, but I'm I could if I put my mind to it, and others here
    > > > > >> almost certainly will.

    >
    > > > > > Ahh, a challange... What if an implementation did something like:

    >
    > > > > > struct {
    > > > > > __flags : 16;
    > > > > > } __errrno;

    >
    > > > > > #define errno (__errno.__flags)

    >
    > > > > __errno.__flags is not a "modifiable lvalue of type int".

    >
    > > > If in some implementation ints are 32 bits, and if we have

    >
    > > > struct { int __flags : 32; } __errno;

    >
    > > > then how is the type of (__errno.__flags) different from int?

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    > > > Certainly (__errno.__flags) is a modifiable lvalue.

    >
    > > > I understand its address cannot be taken with &, but that's
    > > > because it's a bitfield, not because of its type.

    >
    > > Another point: If its type were a bitfield int of 32 bits, then a cast
    > > would make sense;
    > > However, (int : 16) is a syntax error.

    >
    > You do realize don't you that this point is irrelevant to the
    > question that was asked?



    Actually, no, not really. I was trying to make a point why
    __errno.__flags' type is int.
    I replied to the question marked with '^', I thought you did the same.
    , Sep 14, 2008
    #19
  20. viza

    Guest

    On Sep 14, 5:18 pm, Tim Rentsch <> wrote:
    > writes:
    > > On Sep 14, 4:20 pm, Tim Rentsch <> wrote:

    [correcting an article]
    > > > Of course, I meant to say 'signed int' rather than 'int' there...

    >
    > > Why? I don't see how your article is wrong without that correction.

    >
    > Because in bit-fields 'int' is allowed to mean 'unsigned int'
    > or 'signed int'.


    Oh! Thanks. :)
    , Sep 14, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Derek
    Replies:
    7
    Views:
    24,323
    Ron Natalie
    Oct 14, 2004
  2. Trevor

    sizeof(str) or sizeof(str) - 1 ?

    Trevor, Apr 3, 2004, in forum: C Programming
    Replies:
    9
    Views:
    626
    CBFalconer
    Apr 10, 2004
  3. Vinu
    Replies:
    13
    Views:
    1,409
    Lawrence Kirby
    May 12, 2005
  4. blufox

    sizeof( int ) != sizeof( void * )

    blufox, May 22, 2006, in forum: C Programming
    Replies:
    2
    Views:
    554
    Joe Smith
    May 22, 2006
  5. Glenn Linderman

    errno 22 instead of errno 2

    Glenn Linderman, Jan 28, 2009, in forum: Python
    Replies:
    0
    Views:
    361
    Glenn Linderman
    Jan 28, 2009
Loading...

Share This Page