"free space" with declared type

Discussion in 'C Programming' started by S.Tobias, Dec 13, 2004.

  1. S.Tobias

    S.Tobias Guest

    Can an object with a _declared type_ serve as free space?

    union
    {
    char space[ENOUGH];
    maxalign_t unused;
    } _free;

    void *my_malloc(size_t size)
    {
    /*...*/
    return _free.space;
    }

    int main()
    {
    int *pi = my_malloc(sizeof *pi);
    if (pi)
    *pi = 7;
    }

    If I'm not mistaken, the above code should invoke UB, because we
    access an object declared as type char[] with an lvalue of type int.
    Can it cause problems in some environments?
    Is there a better alternative (that doesn't use malloc)? (I'm thinking
    of something similar in idea to "Suba" module in libmba.)

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Dec 13, 2004
    #1
    1. Advertising

  2. S.Tobias

    Eric Sosman Guest

    S.Tobias wrote:
    > Can an object with a _declared type_ serve as free space?


    Yes; the hard part is figuring out what the
    declaration should be.

    > union
    > {
    > char space[ENOUGH];
    > maxalign_t unused;
    > } _free;


    Nitpick: `_free' is an identifier reserved to
    the implementation.

    > void *my_malloc(size_t size)
    > {
    > /*...*/
    > return _free.space;
    > }
    >
    > int main()
    > {
    > int *pi = my_malloc(sizeof *pi);
    > if (pi)
    > *pi = 7;
    > }
    >
    > If I'm not mistaken, the above code should invoke UB, because we
    > access an object declared as type char[] with an lvalue of type int.
    > Can it cause problems in some environments?


    No U.B. that I can see, provided `maxalign_t' is
    aligned strictly enough for an `int'. Data objects are
    defined as sequences of bytes (there's special language
    for bit-fields), and accessing the individual bytes of a
    multi-byte object is permitted. Note that memcpy() would
    make no sense if this were not so; neither would, say,
    fread() and fwrite() when applied to a multi-byte object.

    > Is there a better alternative (that doesn't use malloc)? (I'm thinking
    > of something similar in idea to "Suba" module in libmba.)


    "Is there a better alternative?" Well, what problem
    are you trying to solve? For some problems, the clearly
    superior alternative is exit(0) ;-)

    --
     
    Eric Sosman, Dec 13, 2004
    #2
    1. Advertising

  3. S.Tobias

    S.Tobias Guest

    Eric Sosman <> wrote:
    > S.Tobias wrote:


    > > Can an object with a _declared type_ serve as free space?


    > Yes; the hard part is figuring out what the
    > declaration should be.


    What do you mean? I thought that any non-const object type would be
    good; it's just that "accidentally" char seemed most convenient.
    Am I wrong?

    > Nitpick: `_free' is an identifier reserved to
    > the implementation.


    Thanks, I've changed it to "my_free" now.

    > > union
    > > {
    > > char space[ENOUGH];
    > > maxalign_t unused;

    } my_free;


    > > void *my_malloc(size_t size)
    > > {
    > > /*...*/

    return my_free.space;
    > > }
    > >
    > > int main()
    > > {
    > > int *pi = my_malloc(sizeof *pi);
    > > if (pi)

    {
    > > *pi = 7;

    *pi;
    }
    > > }
    > >
    > > If I'm not mistaken, the above code should invoke UB, because we
    > > access an object declared as type char[] with an lvalue of type int.
    > > Can it cause problems in some environments?


    > No U.B. that I can see, provided `maxalign_t' is
    > aligned strictly enough for an `int'. Data objects are
    > defined as sequences of bytes (there's special language
    > for bit-fields), and accessing the individual bytes of a
    > multi-byte object is permitted.


    I thought that accessing (I have added a line for that) value
    of object(s) of type char with an lvalue of type int was UB.
    I'm referring here to 6.5 #6 and #7. my_free.space has a declared
    type, and it cannot be changed by assignment through an lvalue with
    different type.

    > Note that memcpy() would
    > make no sense if this were not so; neither would, say,
    > fread() and fwrite() when applied to a multi-byte object.


    I'm not quite getting what you mean here. I think memcpy() (and others)
    is not a good example here, because in theory it copies (accesses)
    data by bytes (unsigned char), which is explicitly allowed.

    > > Is there a better alternative (that doesn't use malloc)? (I'm thinking
    > > of something similar in idea to "Suba" module in libmba.)


    > Well, what problem
    > are you trying to solve?


    The problem of UB, of course, which I think takes place there.

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Dec 14, 2004
    #3
  4. S.Tobias

    Jack Klein Guest

    On 14 Dec 2004 02:08:38 GMT, "S.Tobias"
    <> wrote in comp.lang.c:

    > Eric Sosman <> wrote:
    > > S.Tobias wrote:

    >
    > > > Can an object with a _declared type_ serve as free space?

    >
    > > Yes; the hard part is figuring out what the
    > > declaration should be.

    >
    > What do you mean? I thought that any non-const object type would be
    > good; it's just that "accidentally" char seemed most convenient.
    > Am I wrong?
    >
    > > Nitpick: `_free' is an identifier reserved to
    > > the implementation.

    >
    > Thanks, I've changed it to "my_free" now.
    >
    > > > union
    > > > {
    > > > char space[ENOUGH];
    > > > maxalign_t unused;

    > } my_free;
    >
    >
    > > > void *my_malloc(size_t size)
    > > > {
    > > > /*...*/

    > return my_free.space;
    > > > }
    > > >
    > > > int main()
    > > > {
    > > > int *pi = my_malloc(sizeof *pi);
    > > > if (pi)

    > {
    > > > *pi = 7;

    > *pi;
    > }
    > > > }
    > > >
    > > > If I'm not mistaken, the above code should invoke UB, because we
    > > > access an object declared as type char[] with an lvalue of type int.
    > > > Can it cause problems in some environments?

    >
    > > No U.B. that I can see, provided `maxalign_t' is
    > > aligned strictly enough for an `int'. Data objects are
    > > defined as sequences of bytes (there's special language
    > > for bit-fields), and accessing the individual bytes of a
    > > multi-byte object is permitted.

    >
    > I thought that accessing (I have added a line for that) value
    > of object(s) of type char with an lvalue of type int was UB.
    > I'm referring here to 6.5 #6 and #7. my_free.space has a declared
    > type, and it cannot be changed by assignment through an lvalue with
    > different type.


    But an array of char is an array of bytes. I'm not going to bother
    itemizing the reasoning beyond that, I assume you either already agree
    with it or will take my word for it.

    So what exactly is the difference between an uninitialized array of
    ENOUGH chars and the pointer returned by a successful call to
    malloc(ENOUGH)?

    There is one and only one possible difference. The block of SOME_SIZE
    chars returned by malloc() is guaranteed to be suitably aligned for
    any object type, an arbitrary array of chars is not. Anything you can
    store in the block returned by malloc() you can store in the arbitrary
    array of characters, as long as the array is properly aligned for the
    type. And you are assuming that your 'maxalign_t'

    In C, memory is memory is memory, or to use the word the standard does
    in place of memory, storage is storage is storage. Provided that
    alignment requirements are met and const or volatile qualifiers are
    not violated, all storage is the same.

    my_free.space does indeed have a declared type, and is an object. But
    objects do not actually have types, lvalues have types. Note the
    definition of object in 3.14, "region of data storage in the execution
    environment, the contents of which can represent values".

    Once you actually store an object into memory using an lvalue of
    integer type, it contains an integer value. Strictly speaking it no
    longer contains char values, if char is signed on an implementation,
    for one of the bytes of an arbitrary int value might be a trap
    representation for a signed char.

    Accessing an object of type array of chars with an lvalue of type int
    would cause undefined behavior if that object actually contained char
    values. It does not do so if the object actually contains an int
    value.

    Again, other than alignment if your max_aligh_t type is not correct,
    there is no difference at all between your array of chars and the
    block of bytes returned by malloc(). It is only by storing values
    into objects, which must be done by an lvalue of one type or another,
    do the contents take on a value of that type.

    [snip]

    > I'm not quite getting what you mean here. I think memcpy() (and others)
    > is not a good example here, because in theory it copies (accesses)
    > data by bytes (unsigned char), which is explicitly allowed.


    Actually, in theory, memcpy() and others do their work by 'magic', and
    library functions are not bound by the rules that programs are.

    > > > Is there a better alternative (that doesn't use malloc)? (I'm thinking
    > > > of something similar in idea to "Suba" module in libmba.)

    >
    > > Well, what problem
    > > are you trying to solve?

    >
    > The problem of UB, of course, which I think takes place there.


    No UB here, no more than doing the same thing with the pointer
    returned by a successful call to malloc().

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Dec 14, 2004
    #4
  5. S.Tobias

    S.Tobias Guest

    Jack Klein <> wrote:
    > On 14 Dec 2004 02:08:38 GMT, "S.Tobias"
    > <> wrote in comp.lang.c:
    > > Eric Sosman <> wrote:
    > > > S.Tobias wrote:


    > > > > union
    > > > > {
    > > > > char space[ENOUGH];
    > > > > maxalign_t unused;

    > > } my_free;
    > >
    > >
    > > > > void *my_malloc(size_t size)
    > > > > {
    > > > > /*...*/

    > > return my_free.space;
    > > > > }
    > > > >
    > > > > int main()
    > > > > {
    > > > > int *pi = my_malloc(sizeof *pi);
    > > > > if (pi)

    > > {
    > > > > *pi = 7;

    > > *pi;
    > > }
    > > > > }
    > > > >
    > > > > If I'm not mistaken, the above code should invoke UB, because we
    > > > > access an object declared as type char[] with an lvalue of type int.
    > > > > Can it cause problems in some environments?

    > >
    > > > No U.B. that I can see, provided `maxalign_t' is
    > > > aligned strictly enough for an `int'. Data objects are
    > > > defined as sequences of bytes (there's special language
    > > > for bit-fields), and accessing the individual bytes of a
    > > > multi-byte object is permitted.

    > >
    > > I thought that accessing (I have added a line for that) value
    > > of object(s) of type char with an lvalue of type int was UB.
    > > I'm referring here to 6.5 #6 and #7. my_free.space has a declared
    > > type, and it cannot be changed by assignment through an lvalue with
    > > different type.


    > But an array of char is an array of bytes. I'm not going to bother
    > itemizing the reasoning beyond that, I assume you either already agree
    > with it or will take my word for it.


    Yes.

    > So what exactly is the difference between an uninitialized array of
    > ENOUGH chars and the pointer returned by a successful call to
    > malloc(ENOUGH)?


    The difference is pretty abstract, but I think this is the crux
    of the disagreement and of the problem.

    6.5#6 differentiates between objects which have or have not
    declared type (footnote 72 details that allocated objects have
    no declared type). In context of value access, the /effective type/
    of an object *with* declared type is the declared type, always.
    Objects *without* declared type (from malloc()) acquire the effective
    type by storing a value with a type (except character type; the
    effective type is also transmitted through memcpy()).
    This is the difference.

    6.5#7 details rules for accessing value in an object, and is expressed
    in terms of effective type of an object.

    Summary:
    - allocated object acquires and keeps the effective type, a declared
    object does not;
    - reading or writing a value is allowed through an lvalue with
    *compatible* type (or qualified, or un/signed), or character type,
    or through aggregate or union type, which contains the type.

    [snipped alignment provisions]

    [snipped storage quals provisions]

    > my_free.space does indeed have a declared type, and is an object. But
    > objects do not actually have types, lvalues have types. Note the
    > definition of object in 3.14, "region of data storage in the execution
    > environment, the contents of which can represent values".


    Yes, but the Standard in certain contexts associates *effective types*
    with objects.

    > Once you actually store an object into memory using an lvalue of
    > integer type, it contains an integer value. Strictly speaking it no
    > longer contains char values,


    This is the point where I don't agree. This is true for allocated
    objects. But an array with a declared type keeps its effective
    type, no matter what value you store in it or how (the very attempt
    to store such value through an incompatible type lvalue is already UB).

    What's more, although clearly it's not so in the above code, I think
    the compiler in general may assume that `pi' does not point
    into the array `my_free.space' at all.

    I have given all my arguments a few lines above. I don't claim my
    understanding is better; of course, I might be in error. Could you
    please give your arguments, best with pointers to the appropriate places
    in the C Standard. Thanks.

    [snip]


    +++++


    > > I'm not quite getting what you mean here. I think memcpy() (and others)
    > > is not a good example here, because in theory it copies (accesses)
    > > data by bytes (unsigned char), which is explicitly allowed.


    > Actually, in theory, memcpy() and others do their work by 'magic', and
    > library functions are not bound by the rules that programs are.


    I agree; that's why I wrote "in theory" - 'magic' is "in practice".

    In c.s.c. discussion "access via character type" Douglas A. Gwyn
    wrote in <>:
    > See DR #274, which is reflected in TC#2,
    > for a related change we made to the wording of
    > the standard to better reflect our intent in
    > connection with the mem*() functions.


    And the corresponding quote from TC2 is:
    # 73. Page 324, 7.21.1
    # Add a new paragraph 3:
    # For all functions in this subclause, each character shall be
    # interpreted as if it had the type unsigned char (and therefore every
    # possible object representation is valid and has a different value).

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Dec 14, 2004
    #5
  6. S.Tobias

    Jack Klein Guest

    On 14 Dec 2004 22:15:04 GMT, "S.Tobias"
    <> wrote in comp.lang.c:

    > Jack Klein <> wrote:
    > > On 14 Dec 2004 02:08:38 GMT, "S.Tobias"
    > > <> wrote in comp.lang.c:
    > > > Eric Sosman <> wrote:
    > > > > S.Tobias wrote:

    >
    > > > > > union
    > > > > > {
    > > > > > char space[ENOUGH];
    > > > > > maxalign_t unused;
    > > > } my_free;
    > > >
    > > >
    > > > > > void *my_malloc(size_t size)
    > > > > > {
    > > > > > /*...*/
    > > > return my_free.space;
    > > > > > }
    > > > > >
    > > > > > int main()
    > > > > > {
    > > > > > int *pi = my_malloc(sizeof *pi);
    > > > > > if (pi)
    > > > {
    > > > > > *pi = 7;
    > > > *pi;
    > > > }
    > > > > > }
    > > > > >
    > > > > > If I'm not mistaken, the above code should invoke UB, because we
    > > > > > access an object declared as type char[] with an lvalue of type int.
    > > > > > Can it cause problems in some environments?
    > > >
    > > > > No U.B. that I can see, provided `maxalign_t' is
    > > > > aligned strictly enough for an `int'. Data objects are
    > > > > defined as sequences of bytes (there's special language
    > > > > for bit-fields), and accessing the individual bytes of a
    > > > > multi-byte object is permitted.
    > > >
    > > > I thought that accessing (I have added a line for that) value
    > > > of object(s) of type char with an lvalue of type int was UB.
    > > > I'm referring here to 6.5 #6 and #7. my_free.space has a declared
    > > > type, and it cannot be changed by assignment through an lvalue with
    > > > different type.

    >
    > > But an array of char is an array of bytes. I'm not going to bother
    > > itemizing the reasoning beyond that, I assume you either already agree
    > > with it or will take my word for it.

    >
    > Yes.
    >
    > > So what exactly is the difference between an uninitialized array of
    > > ENOUGH chars and the pointer returned by a successful call to
    > > malloc(ENOUGH)?

    >
    > The difference is pretty abstract, but I think this is the crux
    > of the disagreement and of the problem.
    >
    > 6.5#6 differentiates between objects which have or have not
    > declared type (footnote 72 details that allocated objects have
    > no declared type). In context of value access, the /effective type/
    > of an object *with* declared type is the declared type, always.
    > Objects *without* declared type (from malloc()) acquire the effective
    > type by storing a value with a type (except character type; the
    > effective type is also transmitted through memcpy()).
    > This is the difference.
    >
    > 6.5#7 details rules for accessing value in an object, and is expressed
    > in terms of effective type of an object.
    >
    > Summary:
    > - allocated object acquires and keeps the effective type, a declared
    > object does not;
    > - reading or writing a value is allowed through an lvalue with
    > *compatible* type (or qualified, or un/signed), or character type,
    > or through aggregate or union type, which contains the type.
    >
    > [snipped alignment provisions]
    >
    > [snipped storage quals provisions]
    >
    > > my_free.space does indeed have a declared type, and is an object. But
    > > objects do not actually have types, lvalues have types. Note the
    > > definition of object in 3.14, "region of data storage in the execution
    > > environment, the contents of which can represent values".

    >
    > Yes, but the Standard in certain contexts associates *effective types*
    > with objects.
    >
    > > Once you actually store an object into memory using an lvalue of
    > > integer type, it contains an integer value. Strictly speaking it no
    > > longer contains char values,

    >
    > This is the point where I don't agree. This is true for allocated
    > objects. But an array with a declared type keeps its effective
    > type, no matter what value you store in it or how (the very attempt
    > to store such value through an incompatible type lvalue is already UB).
    >
    > What's more, although clearly it's not so in the above code, I think
    > the compiler in general may assume that `pi' does not point
    > into the array `my_free.space' at all.
    >
    > I have given all my arguments a few lines above. I don't claim my
    > understanding is better; of course, I might be in error. Could you
    > please give your arguments, best with pointers to the appropriate places
    > in the C Standard. Thanks.
    >
    > [snip]
    >
    >
    > +++++
    >
    >
    > > > I'm not quite getting what you mean here. I think memcpy() (and others)
    > > > is not a good example here, because in theory it copies (accesses)
    > > > data by bytes (unsigned char), which is explicitly allowed.

    >
    > > Actually, in theory, memcpy() and others do their work by 'magic', and
    > > library functions are not bound by the rules that programs are.

    >
    > I agree; that's why I wrote "in theory" - 'magic' is "in practice".
    >
    > In c.s.c. discussion "access via character type" Douglas A. Gwyn
    > wrote in <>:
    > > See DR #274, which is reflected in TC#2,
    > > for a related change we made to the wording of
    > > the standard to better reflect our intent in
    > > connection with the mem*() functions.

    >
    > And the corresponding quote from TC2 is:
    > # 73. Page 324, 7.21.1
    > # Add a new paragraph 3:
    > # For all functions in this subclause, each character shall be
    > # interpreted as if it had the type unsigned char (and therefore every
    > # possible object representation is valid and has a different value).


    Note the magic words "as if" in this text.

    As for the rest, you are way, way, way over thinking this. Although I
    agree here, as in many other cases, the wording in the standard could
    be much, much clearer.

    Let's look at the terms "declared type" and "effective type".

    For the rest of the discussion, assume that 'ca' defined below meets
    the implementation's alignment requirements for int. And let's assume
    sizeof(int) is 4.

    char ca [sizeof(int)] = { 0 };
    int *ip = (int *)ca;

    The declared type of 'ca' is array of four chars. So far, so good.

    The declared type of 'ip' is pointer to int. Regardless of what
    address 'ip' contains, the effective type of '*ip' is int. Accessing
    the value of '*ip' through its effective type (int) can cause
    undefined behavior for any number of reasons, alignment, invalid
    pointer, trap representation for int, and so on. But not at all how
    the block of memory into which 'ip' points was defined.

    Remember, memory is memory, or storage is storage, or at the lowest
    level in C, bytes is bytes. The declared type of a region of storage
    (that is, the type in the expression that defined and caused storage
    to be allocated) does not change the underlying nature of the bytes.
    There are no bytes that can only hold chars, or ints, or doubles, or
    pointers.

    By the way, if you still aren't convinced, you should take this to
    comp.std.c and see the responses you get there, some from members of
    the C standard committee, perhaps including Doug Gwyn who posts there
    regularly.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Dec 15, 2004
    #6
  7. On Tue, 14 Dec 2004 23:41:50 -0600, Jack Klein wrote:

    ....

    > Let's look at the terms "declared type" and "effective type".
    >
    > For the rest of the discussion, assume that 'ca' defined below meets
    > the implementation's alignment requirements for int. And let's assume
    > sizeof(int) is 4.
    >
    > char ca [sizeof(int)] = { 0 };
    > int *ip = (int *)ca;
    > The declared type of 'ca' is array of four chars. So far, so good.
    >
    > The declared type of 'ip' is pointer to int. Regardless of what
    > address 'ip' contains, the effective type of '*ip' is int.


    Nope. Objects have an effective type, lvalues have a type but it is not
    the "effective type" as defined by C99. C99 6.5p6 says

    "The /effective type/ of an object for an access to its stored value is
    the declared type of the object, if any."

    So the effective type of ca is array of sizeof(int) char. Always. However
    it is accessed. The concept of effective type is used in aliasing rules.
    C90 didn't define an effective type, but it has a problem because malloc'd
    (allocated) objects don't have a declared type so the aliasing rules
    in C90 don't work properly for malloc'd objects. "Effective type" was
    invented to rectify this problem. With a declared effective type mimics
    the C90 semantics i.e. is the same as the declared type, with malloc'd
    objects it depends on what was last written to the object.

    It has to be possible for the effective type of an object to be different
    to the type of an lvalue used to access that object or there would be no
    point in having the term. Specifically rules in C99 6.5p7 such as the
    following depend on this difference:

    "An object shall have its stored value accessed only by an lvalue
    expression that has one of the following types:

    - a type compatible with the effective type of the object

    ....


    - a character type."

    > Accessing
    > the value of '*ip' through its effective type (int) can cause
    > undefined behavior for any number of reasons, alignment, invalid
    > pointer, trap representation for int, and so on. But not at all how
    > the block of memory into which 'ip' points was defined.


    Absolutely because of this, which is what the aliasing rules in 6.5p7 are
    all about. Your example above violates 6.5p7 so it invokes undefined
    behaviour irrespective of any of the other issues you mention. This is
    also true in C90 which makes the same requirements without using the
    concept of effective type (but is broken for malloc'd objects).

    > Remember, memory is memory, or storage is storage, or at the lowest
    > level in C, bytes is bytes.


    Not according to the C standard. Objects also have type associated with
    them. That incidentally includes qualifiers. If you try to access a
    volatile defined object using a non-volatile lvalue you get undefined
    behaviour.

    > The declared type of a region of storage
    > (that is, the type in the expression that defined and caused storage
    > to be allocated) does not change the underlying nature of the bytes.


    But type affects what code is generated to access those bytes.

    > There are no bytes that can only hold chars, or ints, or doubles, or
    > pointers.


    Yes, you could use memcpy() etc. to put anything you like in them. What
    you can't do is use any lvalue you like to put the corresponding type of
    data in a declared object, even if size, alignment const,
    volatile considerations are met. Take an example

    long num = 1;
    short *p = (short *)&l;

    *p = 2;

    This invokes undefined behaviour. The type of the lvalue *p is short but
    the object it is accessing has an effective type of long. This is not a
    combination permitted by C99 6.5p7. It is also undefind by C90 6.3. If
    you're unsure the C90 text is a good place to start.

    Why does the standard make this undefined? For efficiency reasons relating
    to aliasing. Compiler optimisers need to track when an object can be
    accessed in order, for example, to be able to hold its value in a
    register. The compiler knows that num can't be accessed through a
    short lvalue without invoking undefined behaviour and so can safely ignore
    the *p = 2 side-effect for the purposes of optimising access to num. It
    could continue to use the value of num it happened to have held in a
    register, and maybe write it back to the memory object later clobbering
    what was written by *p = 2.

    Lawrence
     
    Lawrence Kirby, Dec 15, 2004
    #7
  8. S.Tobias

    S.Tobias Guest

    Just before I started preparing a post to c.s.c., Lawrence Kirby
    answered Jack Klein's article and took an opposite point of view
    on the issue of type of objects (which I completely agree with).

    What now? Is anybody going to continue here, or shall I open a
    new discussion in c.s.c., as advised by Jack Klein?

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Dec 16, 2004
    #8
  9. On Thu, 16 Dec 2004 15:09:33 +0000, S.Tobias wrote:

    > Just before I started preparing a post to c.s.c., Lawrence Kirby
    > answered Jack Klein's article and took an opposite point of view
    > on the issue of type of objects (which I completely agree with).
    >
    > What now? Is anybody going to continue here, or shall I open a
    > new discussion in c.s.c., as advised by Jack Klein?


    That's up to you and whether you are convinced or not. :)

    Another place to look would be the rationale which has a reasonable
    section on the whole basis of the aliasing rules.

    Lawrence
     
    Lawrence Kirby, Dec 16, 2004
    #9
  10. S.Tobias

    S.Tobias Guest

    Lawrence Kirby <> wrote:
    > On Thu, 16 Dec 2004 15:09:33 +0000, S.Tobias wrote:


    > > What now? Is anybody going to continue here, or shall I open a
    > > new discussion in c.s.c., as advised by Jack Klein?


    > That's up to you and whether you are convinced or not. :)


    I just thought the discussion itself would be very interesting
    to read. But not to keep others unnecessaryly busy, I'll wait
    for a better occasion.

    > Another place to look would be the rationale which has a reasonable
    > section on the whole basis of the aliasing rules.


    Thanks, but I've already known that section before.

    +++

    I would still like to obtain an answer or some comments to my
    original question regarding access of my_free.space in the same
    manner as allocated buffers.

    > Can it cause problems in some environments?


    Could array of some TYPE be allocated in a specific memory for
    the TYPE? From the previous answers I can guess that probably it's
    not a problem in practice, ie. all memory is "equal".

    As for aliasing, I think it is reasonable to assume that no nasal
    daemons would fly out if I clearly separated the code that accesses
    my_free.space as its native type (char[]) and some other type
    (eg. int).

    As a side-note, I think it would be Standard-compliant if pointers
    recorded in their value the object type they're pointing to (this
    is what might break this illegal aliasing). This is similar to
    a case discussed before on aliasing int a[2][2] array, where pointers
    might record the size of an array (this is actually part of
    the type characteristics of the array).

    > Is there a better alternative?


    Well? Any suggestions?

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Dec 18, 2004
    #10
    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. JohnZing

    declared or not declared ?

    JohnZing, Feb 5, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    1,596
    Jon Paal
    Feb 5, 2006
  2. Mark Piffer

    "free space" with declared type

    Mark Piffer, Dec 20, 2004, in forum: C Programming
    Replies:
    2
    Views:
    303
    Lawrence Kirby
    Dec 21, 2004
  3. Mark Piffer

    "free space" with declared type

    Mark Piffer, Dec 21, 2004, in forum: C Programming
    Replies:
    14
    Views:
    474
    Chris Croughton
    Dec 22, 2004
  4. Mark Piffer

    "free space" with declared type

    Mark Piffer, Dec 22, 2004, in forum: C Programming
    Replies:
    1
    Views:
    303
    Chris Torek
    Dec 22, 2004
  5. minil
    Replies:
    11
    Views:
    1,718
    Walter Roberson
    Mar 14, 2005
Loading...

Share This Page