Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Question on Unions in C

Name: Anonymous 2012-06-24 2:12

So, I know that a pointer is a variable that stores a memory address (basic 4 or 8 bytes). If I place a pointer in a Union type, does the memory address stored by the pointer share the same memory space as the other types, or does the data at the memory address share the same memory?

Or, in other words, if I union a double and a char*, will I memory leak/segfault if I assign the double to anything?

Name: Anonymous 2012-06-24 2:15

Name: Anonymous 2012-06-24 2:22

>>1
Pointer types are just syntactic sugar for memory addresses and loading and storing to memory at a given address.

Think of it as an ordinal integer offset into memory, nothing more, that's all it is in assembly/machine language anyway. In C, a pointer can be cast to a intptr_t or uintptr_t as found in the stdint.h header, which are just typedefs for int/long/long long/etc. depending on the target platform.

When you create a union with a pointer, it's no different than creating a union with an intptr_t or uintptr_t, an integer type.

So yes, if you write to the double, you will overwrite the memory address stored in the pointer field and possibly leak/segfault.

Name: Anonymous 2012-06-24 4:22

Is it really that difficult to just test it yourself?


#include <stdio.h>

typedef union {
    long x;
    long* y;
} dickbutt;

int main()
{
    dickbutt shitdick;
    shitdick.x = 0x23;
    printf("0x%x", shitdick.y); // outputs 0x23
}

Name: Anonymous 2012-06-24 5:29

>>4
That is undefined behavior, and depending on the platform the size of a long int pointer type and a long int might be equal so you're basically showing nothing.

Name: Anonymous 2012-06-24 5:31

oh look, this shit again, those 2 pages of the K&R are too long to read right

Name: Anonymous 2012-06-24 6:14

>>5
I'm showing that the pointer itself and not what it points to is what is shared in memory with the rest of the union, which is what the OP asked about you fuckface.

Name: Anonymous 2012-06-24 6:38

>>4
%x is a printf specifier for int, but shitdick.y is a pointer.

You want printf("%p", (void*)shitdick.y);.

Name: Anonymous 2012-06-24 6:42

>>4,8
You need to print a newline too.

Name: Anonymous 2012-06-24 9:34

>>8
It's not fucking relevant to what I'm demonstrating you cockdick.

Name: Anonymous 2012-06-24 10:19

>>7,10
You're a stupid piece of shit.

Name: Anonymous 2012-06-24 15:46

So from what I'm getting in this thread... don't shove pointers in unions, that'll just cause an immediate segfault the second you change anything else. Now I question why the following is done in the Ruby interpreter:

#define RSTRING_EMBED_LEN_MAX ((int)((sizeof(VALUE)*3)/sizeof(char)-1))
struct RString {
    struct RBasic basic;
    union {
        struct {
            long len;
            char *ptr;
            union {
                long capa;
                VALUE shared;
            } aux;
        } heap;
        char ary[RSTRING_EMBED_LEN_MAX + 1];
    } as;
};

ary shares the same space as len, ptr, and aux, and VALUE is a void pointer. Should this not be considered dangerous practice that could easily run into a segfault the second ary is changed and ptr is accessed, or capa is changed and shared is accessed?

Name: Anonymous 2012-06-24 16:11

>>1
If I place a pointer in a Union type, does the memory address stored by the pointer share the same memory space as the other types, or does the data at the memory address share the same memory?
The storage of each union field is shared. This means that the address stored by the pointer shares the same memory space as the other fields in the union. (Not the pointee memory space, if that is your doubt.)

Or, in other words, if I union a double and a char*, will I memory leak/segfault if I assign the double to anything?
Segfault? No, why would it?
Memory leak? Perhaps. Many other factors are involved.

If you assign the double field something, you'll overwrite the address stored in the char* field. Only that.

Now, if you store something in any union field, and then read from any other field (which is not type-compatible with the former), you will invoke undefined behavior.

Name: Anonymous 2012-06-24 16:22

>>12
There's nothing wrong with storing pointers together with other types in an union.

Syntax and code semantics are never wrong per se. Your program, on the other hand, might be wrong because it uses syntax/semantics against the intended goal.

For example, one might create a variant type in C using the following:

struct variant {
    enum type { type_integer, type_string } type;
    union {
        int integer;
        char *restrict string;
   } data;
};

struct variant variant_copy(struct variant variant) {
    struct variant new_variant;
    if (variant.type == type_string) {
        new_variant.data.string = malloc(strlen(variant.data.string) + 1);
        if (!new_variant.data.string)
            abort();
        strcpy(new_variant.data.string, variant.data.string);
    }
    else
        new_variant.data = variant.data;
    new_variant.type = variant.type;
    return new_variant;
}

void variant_free(struct variant variant) {
    if (variant.type == type_string)
        free(variant.data.string);
}

It's perfectly legitimate to employ pointers and other data types in a union type. Just make sure you're accessing the correct fields according to the language rules.

Unions are useful to create a degree of polymorphism in C.

Name: Anonymous 2012-06-24 17:47

>>14
This is a silly way of achieving polymorphism, the effort to maintain the code doesn't scale when the number of types becomes very large.

Unions are useful since the implementation specified behavior for them is very often sane and useful.

Name: Anonymous 2012-06-24 18:09

>>15
Yes, it doesn't scale well. Still it is useful when you know you won't need any more data types.

Name: Anonymous 2012-06-24 18:11

>>15
It will not scale when written by a human, but it will scale if it is written by a machine that is instructed by a human.

Name: Anonymous 2012-06-24 18:51

>>16
That is true, and it was an apt use of unions to highlight desirable behavior.

>>17
It is unnecessary to waste timing trying to fix something that isn't broken, if you want polymorphism you use vtables and selectors, then adding, modifying or removing a type does not mandate change of code in any other area of your program/library.

Name: Anonymous 2012-06-24 20:12

>>18
whether or not vtables are broken depends on the use case. They are not necessarily sufficient for all applications, and in those cases, it can be useful to look into an alternative implementation for polymorphism.

Name: Anonymous 2012-06-25 4:24

>>11
Suck my dick, faggot.

Name: Anonymous 2012-06-25 12:15

啅饕刔㢈鞁㝄㎁刹䝁㞘坰嘸䌁⌠眹甲呖堥萇犐冁ᘅ酕ሦ鉣憂╕䢗ᝣ␁嚐҈ᡠ䡉奡酀鞅鎄撕᠃㥄瘡䘂芇ፓ灱䦓偦♠㔴㈖㡄蔤ᡦ吥錹䀨䎓挳ሂ顆ᦂ⊘阔礓恕⊘⢘鍃搹ᘆ䀸䦃Ź蕷ㅠ㝣ₔ礹褗蕵襧奖⒄ݴ⍱戂艒銅圴攥䠲ࡱPy顢蔖䚀虷䉥瀶捀ᆗ┷䘗夔牸怴ᙆ㦃祒祹呷蠷焒鈡虅H褄ܦ抉"ʙ儤䌁ɉ啤‗䌲耧遑疒㖅❇码阹劉呔␢㢕虶⢒進甙㤨猉䥗⎗蠩镩㢅䐓鎒̰畤憆䀉䔕ጃ剉莅阤掓昄ؖգ❧蜳䐣牵褀鐘硨㑖瞐靳鐵呹璈醄塅鍅䀗腩ᠣ†瑔啹㠇䐡焗鞁晇脥ޘ㌤畳襙慢衣䈶㎂邕桓桡硅˜肆聰蝑醈舖㝗靐㎙慁省≱饤䀰捕酱㜤❴䍒扩茱蠰圓搦ញ倱㤉猇蔵皕顱祒蝗桄䍁琒瑸ᙉ喖☀㔦ᘉ€こ袖荹ᕓᅷ⡤䜂䦅灃餘捇❄倈虀榘㖔䉐⠉᠑锤゗ぅ栴蕑萩͡鉩㡒遑扢᠔噴鑨ㄑ儨奩衳蕥つᢉ䕗牖甔蘧锆膐ᐱす䅒蔒R

Name: Anonymous 2012-06-25 12:29

┦捅╆䐓጑腲蒙剈斒じ㝁昙阰ᆅ礡㞇䥰⤖楁व怵ܤͳᄘ匥㘃鑳ᑳ硹ᔨ䑃捰ぃԱ吉ኙ猩坔C願禒搀䤶䘕桅呂畵ᡇ栧牁䆖悆┵萧饄劙蔨劖灲瀤栓⒅ᕢ愧逸䍩睖䡙㄃〙ᥴ䁢㔒鉡ភᒑ円ᐰ悐ᅱ†爄鈢䘄⍨ፘᄔ⑥ܹॴ䍷犓Š瑓ⅷ቉捔‹䠆℆㌅ᔄ蘉㢈ᔣ钅舄㞂靱␆ᚃ⥥у獩䉥吀⢑蔡萀捈ᅸᐓ蔵撑ቲ㝒䡓桐持㝲茨㌴㥣、ቀᙀ匘ց頕炐器夹ᒙᤀ͖荵ᑂ吆馔ᜑŦᎁᄒЦ锦唳㝴㍉ᙡ鍖瑘ؙ䤗ᐒձܱ̉⅖祒㝐ぁឃ⌁處з鈕䅈匷᥵ऑ垇ᡅ霨皖祗蜕楕ᡑ芓ᥕ硈ሙ㍤吒ɆĂ噥褷唔ȳ琑ঘ㤇Ⅳ術瘠ᔖ祇薗蘈㊄∓ई䕂塴猸祂ѡㅀ䦃蚉褢℗⦈在莃ܔ陒ձᔇ噉匇䀤䍓㕥虂㥄灰䞅Ͳ鉴ᖂ呷䀙ቀ㢒шᄗ⅖Ց㐹↕䞆坲㞘儁礦ԖͰ舀鑨肀ႃᤅ睐ᅶѐ畦ᥣፐ虖ᒐ㒄杔悉⥖⦃䈩䑧颀蠤ጄᢗ顕瑁鄨犖獑ƕ㥅ᘶ䖓艡㥄↕愴ԡ⤁茂स

Name: bampu pantsu 2012-06-26 2:59

bampu pantsu

Don't change these.
Name: Email:
Entire Thread Thread List