[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Query abt union

unknown

6/23/2011 8:07:00 PM

Hi,

I have some experience in C prog lang. I have small doubt abt using
unions in C lang.

I have the foll. union

union MyUnion
{
char name [100];
double dblval;
int intVal;
};

Since all the members of union share the same memory space, if we set
the val of one union members, it overwr. the other field's value.
How do the OS maintain that a partic. member is set and not the
other member.

Say like, I use

MyUnion ux;

strncpy(ux.name, "C Language", strlen("C Langage")); /* name is set */

/* try to overwr. name field */

ux.intVal = 0xFF6677;

Now at this time how does OS maintains that intVal is now used... !!!!

Also, if I now try to print name field, what it shld be ??

Pls reply in ur FREE time..there is no urgency..

sumit
27 Answers

Ben Pfaff

6/23/2011 8:19:00 PM

0

"sumit.sharma" <nospam@nospam.com> writes:

[in a union]
> How do the OS maintain that a partic. member is set and not the
> other member.

It doesn't. It's the responsibility of the code that uses to
union to keep track of which member has most recently been
assigned.
--
Ben Pfaff
http://be...

Shao Miller

6/23/2011 10:21:00 PM

0

On 6/23/2011 3:07 PM, sumit.sharma wrote:
> Hi,
>
> I have some experience in C prog lang. I have small doubt abt using
> unions in C lang.
>
> I have the foll. union
>
> union MyUnion
> {
> char name [100];
> double dblval;
> int intVal;
> };
>
> Since all the members of union share the same memory space, if we set
> the val of one union members, it overwr. the other field's value.
> How do the OS maintain that a partic. member is set and not the
> other member.
>
> Say like, I use
>
> MyUnion ux;
>

I have a doubt about your line, above.

union MyUnion ux;

> strncpy(ux.name, "C Language", strlen("C Langage")); /* name is set */
>

I have a doubt about your line, above.

/* Set the 'name' member */
strncpy(ux.name, "C Language", sizeof ux.name);

> /* try to overwr. name field */
>
> ux.intVal = 0xFF6677;
>
> Now at this time how does OS maintains that intVal is now used... !!!!
>

Already answered by someone else.

> Also, if I now try to print name field, what it shld be ??
>

You should doubt that it will be useful as a "name".

John Gordon

6/23/2011 10:28:00 PM

0

In <iu06d5$cnu$1@speranza.aioe.org> "sumit.sharma" <nospam@nospam.com> writes:

> strncpy(ux.name, "C Language", strlen("C Langage")); /* name is set */

This seems needlessly complicated. Why wouldn't you just do:

strcpy(ux.name, "C Language")

--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

Lew Pitcher

6/23/2011 10:47:00 PM

0

On June 23, 2011 16:07, in comp.lang.c, nospam@nospam.com wrote:

[snip]
> union MyUnion
> {
> char name [100];
> double dblval;
> int intVal;
> };
>
[snip]
>> MyUnion ux;
>
> strncpy(ux.name, "C Language", strlen("C Langage")); /* name is set */

As an aside, the above illustrates a common problem found when programmers
overuse string literals. Here, the strncpy() will result in ux.name being
set to the string array "C Languag", dropping the final "e"

Do you see why? Hint: it has to do with the string literals.


[snip]

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfr... | Just Linux: http://jus...
---------- Slackware - Because I know what I'm doing. ------


Shao Miller

6/23/2011 10:55:00 PM

0

On 6/23/2011 5:47 PM, Lew Pitcher wrote:
> On June 23, 2011 16:07, in comp.lang.c, nospam@nospam.com wrote:
>
> [snip]
>> union MyUnion
>> {
>> char name [100];
>> double dblval;
>> int intVal;
>> };
>>
> [snip]
>>> MyUnion ux;
>>
>> strncpy(ux.name, "C Language", strlen("C Langage")); /* name is set */
>
> As an aside, the above illustrates a common problem found when programmers
> overuse string literals. Here, the strncpy() will result in ux.name being
> set to the string array "C Languag", dropping the final "e"
>
> Do you see why? Hint: it has to do with the string literals.
>
>
> [snip]
>

It also doesn't copy the null terminator, if I'm not mistaken. Since
'ux.name' has a limit, I think using that limit makes some sense.

Joe Pfeiffer

6/23/2011 11:13:00 PM

0

Lew Pitcher <lpitcher@teksavvy.com> writes:

> On June 23, 2011 16:07, in comp.lang.c, nospam@nospam.com wrote:
>
> [snip]
>> union MyUnion
>> {
>> char name [100];
>> double dblval;
>> int intVal;
>> };
>>
> [snip]
>>> MyUnion ux;
>>
>> strncpy(ux.name, "C Language", strlen("C Langage")); /* name is set */
>
> As an aside, the above illustrates a common problem found when programmers
> overuse string literals. Here, the strncpy() will result in ux.name being
> set to the string array "C Languag", dropping the final "e"
>
> Do you see why? Hint: it has to do with the string literals.

Ah, I didn't see that one (requires very careful reading!). I was about
to post another, worse bug in the same line: it guarantees no trailing
null at the end of the string (we just had a brief discussion of
strncpy()'s problem in this regard!). Better would be

strncpy(ux.name, "C Language", sizeof(ux.name));
ux.name[sizeof(ux.name)-1] = '\0';

Though this is, of course, inefficient.

Somebody else suggested using strcpy(); since the string being copied is
a literal a good code review will would then establish no buffer
overrun.

Keith Thompson

6/24/2011 12:19:00 AM

0

Shao Miller <sha0.miller@gmail.com> writes:
> On 6/23/2011 5:47 PM, Lew Pitcher wrote:
>> On June 23, 2011 16:07, in comp.lang.c, nospam@nospam.com wrote:
>>
>> [snip]
>>> union MyUnion
>>> {
>>> char name [100];
>>> double dblval;
>>> int intVal;
>>> };
>>>
>> [snip]
>>>> MyUnion ux;
>>>
>>> strncpy(ux.name, "C Language", strlen("C Langage")); /* name is set */
>>
>> As an aside, the above illustrates a common problem found when programmers
>> overuse string literals. Here, the strncpy() will result in ux.name being
>> set to the string array "C Languag", dropping the final "e"
>>
>> Do you see why? Hint: it has to do with the string literals.
>> [snip]
>
> It also doesn't copy the null terminator, if I'm not mistaken. Since
> 'ux.name' has a limit, I think using that limit makes some sense.

But since strncpy() pads the destination with nulls, ux.name ends up
containing a valid string (and 91 nulls where 1 would do).

General rule: Don't use strncpy unless you really understand what it
does. (And if you understand what it does, you probably won't want to
use it.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Joe Pfeiffer

6/24/2011 4:12:00 AM

0

Keith Thompson <kst-u@mib.org> writes:
<lots snipped>
> But since strncpy() pads the destination with nulls, ux.name ends up
> containing a valid string (and 91 nulls where 1 would do).
>
> General rule: Don't use strncpy unless you really understand what it
> does. (And if you understand what it does, you probably won't want to
> use it.)

It really is too bad there isn't a good library function to copy a
string safely -- building one on top of memcpy() or even doing it by
hand is easy, but it would be better if it were in the library.

Is the implementation of snprintf() typically efficient enough to make
sense for this purpose?

Keith Thompson

6/24/2011 5:32:00 AM

0

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
> <lots snipped>
>> But since strncpy() pads the destination with nulls, ux.name ends up
>> containing a valid string (and 91 nulls where 1 would do).
>>
>> General rule: Don't use strncpy unless you really understand what it
>> does. (And if you understand what it does, you probably won't want to
>> use it.)
>
> It really is too bad there isn't a good library function to copy a
> string safely -- building one on top of memcpy() or even doing it by
> hand is easy, but it would be better if it were in the library.

Something like this is pretty close:

#define STRNCPY(dest, src, n) \
(*(dest) = '\0', strncat((dest), (src), (n)))

It evaluates dest twice, but that shouldn't be a problem.

[...]

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Joe Pfeiffer

6/24/2011 2:52:00 PM

0

Keith Thompson <kst-u@mib.org> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>> <lots snipped>
>>> But since strncpy() pads the destination with nulls, ux.name ends up
>>> containing a valid string (and 91 nulls where 1 would do).
>>>
>>> General rule: Don't use strncpy unless you really understand what it
>>> does. (And if you understand what it does, you probably won't want to
>>> use it.)
>>
>> It really is too bad there isn't a good library function to copy a
>> string safely -- building one on top of memcpy() or even doing it by
>> hand is easy, but it would be better if it were in the library.
>
> Something like this is pretty close:
>
> #define STRNCPY(dest, src, n) \
> (*(dest) = '\0', strncat((dest), (src), (n)))
>
> It evaluates dest twice, but that shouldn't be a problem.

Ah, nice. I'll have to remember that...