Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > How to extract bytes from a long?

Reply
Thread Tools

How to extract bytes from a long?

 
 
CBFalconer
Guest
Posts: n/a
 
      10-16-2003
Joe Wright wrote:
>

.... snip ...
>
> I contend, as you seem to, that accessing u.lng as components of
> u.byt[] is what unions are all about. We could be wrong.


You are. The purpose is to conserve storage space when only one
of a variety of facets of the object needs to be recorded.

>
> Accessing memory through (unsigned char *) seems to be guaranteed
> to work. I demonstrate both methods below. I don't understand why
> the first is wrong while the second is right. Duck!


Again, this depends on the objective. If you want to examine all
the bits in the machine, including any padding or trap value bits,
yes. If you want to extract bits from the long value, no, because
they may well include bits extraneous to the value.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

 
Reply With Quote
 
 
 
 
Mike Wahler
Guest
Posts: n/a
 
      10-16-2003
"cody" <(E-Mail Removed)> wrote in message
news:bmkifg$n74rj$(E-Mail Removed)-berlin.de...

> You should not assign new values to byt, that could cause trap
> representations as you said, but reading is allowed and safe.


At first I too made similar unfounded assertions here,
due to my ignorance, but I *listened* when shown that
I was wrong.

-Mike



 
Reply With Quote
 
 
 
 
bd
Guest
Posts: n/a
 
      10-16-2003
cody wrote:

>> > > >I'm suprised no one suggested a union!
>> > > >
>> > > >#include <stdio.h>
>> > > > union _x
>> > > > {
>> > > > long lng;
>> > > > char byt[4];
>> > >
>> > > Stop right here: what makes you think a long is four chars wide?
>> >
>> > That could be easily overcome with sizeof. It's more that you can't
>> > rely

> on
>> > the byte order if you try to do it portably.

>>
>> No, the problem is that you can't write into one union field and read
>> from another.

>
>
> Isn't that what a union is good for???


They're intended as convenient ways of storing one out of several types in
one field. E.g., in a lexer or parser you might use something like:

struct token {
enum { TOKEN_FOO, TOKEN_BAR } type;
union {
struct token_foo_data foo;
struct token_bar_data bar;
} data;
};

Then, when processing the tokens, read the enum, and then read one of the
union fields based on the enum.
 
Reply With Quote
 
cody
Guest
Posts: n/a
 
      10-16-2003
"Irrwahn Grausewitz" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> "cody" <(E-Mail Removed)> wrote:
> >> >> #include <stdio.h>
> >> >> union _x
> >> >> {
> >> >> long lng;
> >> >> char byt[sizeof long];
> >> >> }

[..]
> >> For completeness, there's also a syntax error.

> >
> >The missing semicolon at the end?

>
> Actually, there are two syntax errors, of which the
> missing semicolon is one.



OK, OK..

sizeof ( long )

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


 
Reply With Quote
 
cody
Guest
Posts: n/a
 
      10-16-2003
>>> #include <stdio.h>
>>> union _x
>>> {
>>> long lng;
>>> char byt[sizeof long];
>>> }


> > You should not assign new values to byt, that could cause trap
> > representations as you said, but reading is allowed and safe.

>
> No it isn't. You have been told in another post that it is not.



When both variables in the union starts at the same address, writing to one
and reading from the other is safe.

Note the special guarantee:
[#5] With one exception, if the value of a member of a union
object is used when the most recent store to the object was
to a different member, the behavior is
implementation-defined.6 One special guarantee is made in
order to simplify the use of unions: If a union contains
several structures that share a common initial sequence (see
below), and if the union object currently contains one of
these structures, it is permitted to inspect the common
initial part of any of them anywhere that a declaration of
the completed type of the union is visible. Two structures
share a common initial sequence if corresponding members
have compatible types (and, for bit-fields, the same widths)
for a sequence of one or more initial members
--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      10-16-2003
cody wrote:
>
> When both variables in the union starts at the same address, writing to one
> and reading from the other is safe.


Nonsense. *Every* variable in a union starts at the same
address (every addressable variable, that is: bit-fields have
no addresses as far as C is concerned).

> Note the special guarantee:
> [#5] With one exception, if the value of a member of a union
> object is used when the most recent store to the object was
> to a different member, the behavior is
> implementation-defined.6 One special guarantee is made in
> order to simplify the use of unions: If a union contains
> several structures that share a common initial sequence (see
> below), and if the union object currently contains one of
> these structures, it is permitted to inspect the common
> initial part of any of them anywhere that a declaration of
> the completed type of the union is visible. Two structures
> share a common initial sequence if corresponding members
> have compatible types (and, for bit-fields, the same widths)
> for a sequence of one or more initial members


The special guarantee applies only to union members
that happen to be structs, and only to structs if they
"share a common initial subsequence." The union you
exhibited contained no structs at all, and is not covered
by the special guarantee.

Are you having trouble understanding the English in
which the Standard is written? You appear to be posting
from a .de address, which might indicate that your native
language is German. The great number of grammatical errors
in your written English makes me think you must be American,
but if not -- well, your English is better than my German,
but perhaps not equal to the task of deciphering Standardese.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      10-16-2003

On Thu, 16 Oct 2003, cody wrote:
>


As you have been told several times before, *don't snip attributions!*
They exist so that we can tell who said what.

> >>> #include <stdio.h>
> >>> union _x
> >>> {
> >>> long lng;

char byt[sizeof (long)];
};
>
> > > You should not assign new values to byt, that could cause trap
> > > representations as you said, but reading is allowed and safe.

> >
> > No it isn't. You have been told in another post that it is not.

>
> When both variables in the union starts at the same address, writing
> to one and reading from the other is safe.


What part of "No it isn't" don't you understand? I think [whoever
that was] was *very* clear, and you can't claim misunderstanding
here.

> Note the special guarantee:
> [#5] With one exception, if the value of a member of a union
> object is used when the most recent store to the object was
> to a different member, the behavior is
> implementation-defined.


Boom. Implementation-defined. Sure, it's not undefined behavior,
but it's certainly not portable (which is what "safe" usually
connotes in the context of c.l.c).

> 6 One special guarantee is made in
> order to simplify the use of unions: If a union contains

^^
> several structures that share a common initial sequence (see

^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
> below), and if the union object currently contains one of
> these structures, it is permitted to inspect the common
> initial part of any of them anywhere that a declaration of
> the completed type of the union is visible. Two structures
> share a common initial sequence if corresponding members
> have compatible types (and, for bit-fields, the same widths)
> for a sequence of one or more initial members


Right. Note the special guarantee.

It's nice that you've learned where to find the draft standard;
now if only you'd read it more carefully...

[Oh, and re the "4 bytes to 3 bytes" thread, you're wrong over there
too. Structure padding between bit-field members is implementation-
defined, and the standard says nothing about compiler switches.]

-Arthur

 
Reply With Quote
 
cody
Guest
Posts: n/a
 
      10-16-2003
"Eric Sosman" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> cody wrote:
> >
> > When both variables in the union starts at the same address, writing to

one
> > and reading from the other is safe.

>
> Nonsense. *Every* variable in a union starts at the same
> address (every addressable variable, that is: bit-fields have
> no addresses as far as C is concerned).


union
{
int a;
struct
{
int b;
int c;
} X;
}

Note that a and c have different starting points. Bitfield does have an
address, while the bits they contain have not.

> > Note the special guarantee:
> > [#5] With one exception, if the value of a member of a union
> > object is used when the most recent store to the object was
> > to a different member, the behavior is
> > implementation-defined.6 One special guarantee is made in
> > order to simplify the use of unions: If a union contains
> > several structures that share a common initial sequence (see
> > below), and if the union object currently contains one of
> > these structures, it is permitted to inspect the common
> > initial part of any of them anywhere that a declaration of
> > the completed type of the union is visible. Two structures
> > share a common initial sequence if corresponding members
> > have compatible types (and, for bit-fields, the same widths)
> > for a sequence of one or more initial members

>
> The special guarantee applies only to union members
> that happen to be structs, and only to structs if they
> "share a common initial subsequence." The union you
> exhibited contained no structs at all, and is not covered
> by the special guarantee.


#include <stdio.h>
union X
{
struct { long lng} A;
struct { char byt[sizeof (long)] } B;
};

And now? Two structs with a common starting point.

> Are you having trouble understanding the English in
> which the Standard is written?


I try my best

> You appear to be posting
> from a .de address, which might indicate that your native
> language is German.


That is correct, I'm german.

> The great number of grammatical errors
> in your written English makes me think you must be American,
> but if not -- well, your English is better than my German,


I didn't know grammar of American and British is different.

> but perhaps not equal to the task of deciphering Standardese.


Honestly, not a simple task.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


 
Reply With Quote
 
cody
Guest
Posts: n/a
 
      10-16-2003
"Arthur J. O'Dwyer" <(E-Mail Removed)> schrieb im Newsbeitrag
news(E-Mail Removed)...

> [Oh, and re the "4 bytes to 3 bytes" thread, you're wrong over there
> too. Structure padding between bit-field members is implementation-
> defined, and the standard says nothing about compiler switches.]


Does that mean in standard C you have no control over structure padding?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


 
Reply With Quote
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      10-16-2003

On Fri, 17 Oct 2003, cody wrote:
>
> "Eric Sosman" <(E-Mail Removed)> schrieb...
> > cody wrote:
> > >
> > > When both variables in the union starts at the same address, writing
> > > to one and reading from the other is safe.

> >
> > Nonsense. *Every* variable in a union starts at the same
> > address (every addressable variable, that is: bit-fields have
> > no addresses as far as C is concerned).

>
> union
> {
> int a;
> struct
> {
> int b;
> int c;
> } X;

};
>
> Note that a and c have different starting points.


Correct. Eric should have said, "Every *member* of a union starts
at the same address"; note that 'a' and 'X' have the same address.

> Bitfield does have an
> address, while the bits they contain have not.


Incorrect. One cannot take the address of a bit-field member.


> > The special guarantee applies only to union members
> > that happen to be structs, and only to structs if they
> > "share a common initial subsequence." The union you
> > exhibited contained no structs at all, and is not covered
> > by the special guarantee.

>
> #include <stdio.h>
> union X
> {
> struct { long lng} A;
> struct { char byt[sizeof (long)] } B;
> };
>
> And now? Two structs with a common starting point.


And a common initial sequence of length zero. So you can write
zero bytes to &some_x.A, and read zero bytes from &some_x.B,
portably.

union Example {
struct { long x; } A;
struct { long y; long z; } B;
} ex;

Union 'Example' contains two structures with a common initial
sequence of length sizeof(long) bytes. Thus, one may portably
write to ex.A.x and then immediately read from ex.B.y, and
expect to get the same value back.


> > The great number of grammatical errors
> > in your written English makes me think you must be American,
> > but if not -- well, your English is better than my German,

>
> I didn't know grammar of American and British is different.


The fact that the great number of grammatical errors in your
written English made Eric think you must have been American,
makes me think Eric must be British.

-Arthur
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Ratio of Bytes Delayed to Bytes Sent netproj Cisco 0 12-21-2005 08:08 PM
Private Bytes vs. # Bytes in all Heaps in Perfmon Jason Collins ASP .Net 3 02-18-2004 03:59 PM
Re: receiving Bytes and sending Bytes Ieuan Adams Computer Support 0 07-24-2003 07:46 PM
Re: receiving Bytes and sending Bytes The Old Sourdough Computer Support 0 07-23-2003 01:23 PM



Advertisments