Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #30378

Re: Struct assignment

Show all headers | View raw

On 20/01/13 17:06, Shao Miller wrote:
> On 1/19/2013 21:21, Russell Shaw wrote:
>> On 20/01/13 03:45, Shao Miller wrote:
>>> On 1/19/2013 09:18, Russell Shaw wrote:
>>>> On 20/01/13 00:27, Eric Sosman wrote:
>>>>> On 1/19/2013 7:09 AM, Russell Shaw wrote:
>>>>>> Hi,
>>>>>> In gcc-4.7 C99, i get an error (in a function scope):
>>>>>>
...
>>> Suppose you have:
>>>
>>> typedef int tni;
>>> struct { int size; } apple;
>>> struct { tni size; } orange;
>>>
>>> Should these two objects be considered to have the same type, if we saw
>>> these in the same translation unit? It could be that the _intention_ is
>>> for each to belong to a different domain, and the discussion of
>>> compatible types helps to prevent against accidental crossing of
>>> domains.
>>
>> That's what i'd like to see,
>
> That's not what _I'd_ like to see! I want type safety that allows me to specify
> different domains of values, without any care for internal representational
> co-incidences. I don't want to accidentally compare apples and oranges.

That's what i meant (the safer option).

>> but i was trying to figure out how assignments between them can be done if
>> they come from different translation units.
>
> Translation unit #1:
>
> struct { int i; double d; } foo;
>
> Translation unit #2:
>
> extern struct { int i; double d; } foo;
>
> Now the type of 'foo' in TU #1 can be said to be compatible with the type in TU #2.
>
>> I cannot devise how sb = sa can be found in any source, where sb and sa
>> have separate struct declarations.
>>
> Why you are searching for such a case?

Just to see if it should be possible or not (i'm doing a compiler).

> Type compatibility is used in a lot of places other than assignment. As just
> one example, suppose you have:
>
> Translation unit #1:
>
> static struct { int i; double d; } foo;
> void * foo_ptr = &foo;
>
> void callme(void) {
> if (foo.i == 42 && foo.d == 3.14159)
> /* Success */
> return;
> }
>
> Translation unit #2:
>
> extern void callme(void);
> extern void * foo_ptr;
>
> static struct { int i; double d; } bar;
>
> static void somefunc(void) {
> bar.i = 42;
> bar.d = 3.14159;
> memcpy(foo_ptr, &bar, sizeof bar);
> callme();
> }
>
> If 'foo' and 'bar' didn't have compatible types, then when 'somefunc' calls
> 'callme' and 'callme' tries to read the value of 'foo.i' and 'foo.d', it'd be
> undefined behaviour. Because they have compatible types, things are ok.
>
>>
>> The only use case i can think of is:
>>
>>
>> Translation unit1:
>>
>> // tu1.h header:
>> struct {
>> int a;
>> } sb;
>>
>> struct sb *str_new(void);
>>
>>
>> // tu1.c
>> struct {
>> int a;
>> } sa;
>>
>> struct sa *str_new(void)
>> {
>> struct sa *str = malloc(sizeof(struct sa));
>> return str;
>> }
>
> I don't quite follow the point of this code.
>
> (Minor note: The pattern:
>
> obj_type * ptr = malloc(sizeof *ptr);
>
> says "Allocate enough storage for the pointee" whereas your version says
> "Allocate enough storage for obj_type", which happens to match the right size
> for the pointee.)
>
> Here is a thought experiment:
>
> Imagine that 9 out of 10 people want:
>
> struct { int i; } root;
>
> to represent a one-of-a-kind object, that should never be compared with any
> other object, even if there is an object like:
>
> struct { int i; } starting_point;
>
> Now imagine that you need to be able to access 'root' from any other translation
> unit. You can make a header for those _other_ translation units:
>
> extern struct { int i; } root;
>
> Because the header is actually part of each of the other translation units, type
> compatibility says that the all of the translation units think that 'root' is
> the same type.
>
> Here is a different thought experiment:
>
> Imagine that 1 out of 10 people want:
>
> struct { int i; } count;
>
> and:
>
> struct { int i; } number;
>
> to have the same type because they have the same composition, and want to be
> able to assign the values of these objects to one another because both are
> objects that might make sense in the same domain.
>
> Now imagine that 1 out of 10 people see a strange rule that seems to interfere
> with this goal, but seems to allow it when the objects are in different
> translation units. In fact, if the two objects are declared in two translation
> units (as a header #inclusion would do), the allowance doesn't even have any
> benefit for the goal!
>
> But the two sets of people in these thought experiments have different goals.
> These thought experiments aren't offered as an actual representation of the
> world, but as a possible way to understand how people with different goals can
> view the rules very differently.
>
> (The 9 people might say to the 1 person, "so identify the type so it can be
> re-used, then we both win, to an extent.")

I'll implement the safer option. The standard is a bit ambiguous without the 
context of existing "practice".

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-19 23:09 +1100
  Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-19 08:27 -0500
    Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-20 01:18 +1100
      Re: Struct assignment "BartC" <bc@freeuk.com> - 2013-01-19 14:59 +0000
      Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-19 11:25 -0500
        Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-20 12:46 +1100
          Re: Struct assignment Bart van Ingen Schenau <bart@ingen.ddns.info.invalid> - 2013-01-20 09:20 +0000
          Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-20 09:08 -0500
            Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-21 12:02 +1100
              Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-20 22:08 -0500
                Re: Struct assignment James Kuyper <jameskuyper@verizon.net> - 2013-01-20 23:21 -0500
              Re: Struct assignment James Kuyper <jameskuyper@verizon.net> - 2013-01-21 08:23 -0500
                Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-22 13:33 +1100
                Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-23 19:53 +1100
      Re: Struct assignment Shao Miller <sha0.miller@gmail.com> - 2013-01-19 11:45 -0500
        Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-20 13:21 +1100
          Re: Struct assignment Shao Miller <sha0.miller@gmail.com> - 2013-01-20 01:06 -0500
            Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-20 18:03 +1100
  Re: Struct assignment glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-19 19:18 +0000
    Re: Struct assignment James Kuyper <jameskuyper@verizon.net> - 2013-01-19 15:22 -0500
      Re: Struct assignment Shao Miller <sha0.miller@gmail.com> - 2013-01-19 15:47 -0500
      Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-19 17:56 -0500
        Re: Struct assignment Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-20 12:12 -0800
  Re: Struct assignment falk@rahul.net (Edward A. Falk) - 2013-01-19 23:41 +0000
    Re: Struct assignment glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-20 01:01 +0000
    Re: Struct assignment James Kuyper <jameskuyper@verizon.net> - 2013-01-19 20:53 -0500
      Re: Struct assignment Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-20 12:03 -0800

csiph-web