C to Java Byte Code

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Thomas G. Marshall

    #61
    Re: C to Java Byte Code

    Old Wolf coughed up:[color=blue]
    > Paul Lutus <nospam@nosite. zzz> wrote:[color=green]
    >> Show us the bytecode that overlays a Java float and a Java integer
    >> into the same memory space. That is what a union is.[/color]
    >
    > Sorry, you are wrong. There is no requirement in the C standard for
    > the members of the union to occupy the same piece of memory.
    > If you disagree then please quote a standard reference.
    > (They must all return the same thing when their address is
    > taken and then converted to (void *), but it does not follow
    > from that that they occupy the same physical memory).
    >[color=green]
    >> Show us the Java bytecode that allows one to manipulate
    >> individual bits of a Java float datatype, as a C union allows.[/color]
    >
    > A C union does not allow that. Any C program that
    > relies on it is non-portable.
    >
    > The following results are conforming to the C specification
    > (note, this is a minor modification of a program posted
    > elsewhere in the thread):
    >
    > #include <stdio.h>
    >
    > typedef union abc
    > { int x;
    > float y;
    > } a_union;
    >
    > main()
    > { a_union z;
    >[/color]

    First example:[color=blue]
    > z.x = 1;
    > printf("int val = %d\n", z.x);
    > printf("float val = %f\n", z.y);
    >[/color]

    Second example:[color=blue]
    > z.y = 3.142;
    > printf("int val = %d\n", z.x);
    > printf("float val = %f\n", z.y);
    > return 0;
    > }
    >
    > Results:
    > int val = 1
    > float val = 3.142
    > int val = 1
    > float val = 3.142[/color]


    How does the mini-PI come out of a union (first example) that was only set
    with integer 1?

    How does a 1 get pulled out of a union set with a value of mini-PI? A
    /structure would do that at this point, since .x was set to 1, but not a
    union.

    Unless I'm going nuts here (possible)...

    --
    Framsticks. 3D Artificial Life evolution. You can see the creatures
    that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
    me). http://www.frams.alife.pl/


    Comment

    • Thomas G. Marshall

      #62
      Re: C to Java Byte Code

      Thomas G. Marshall coughed up:[color=blue]
      > Old Wolf coughed up:[color=green]
      >> Paul Lutus <nospam@nosite. zzz> wrote:[color=darkred]
      >>> Show us the bytecode that overlays a Java float and a Java integer
      >>> into the same memory space. That is what a union is.[/color]
      >>
      >> Sorry, you are wrong. There is no requirement in the C standard for
      >> the members of the union to occupy the same piece of memory.
      >> If you disagree then please quote a standard reference.
      >> (They must all return the same thing when their address is
      >> taken and then converted to (void *), but it does not follow
      >> from that that they occupy the same physical memory).
      >>[color=darkred]
      >>> Show us the Java bytecode that allows one to manipulate
      >>> individual bits of a Java float datatype, as a C union allows.[/color]
      >>
      >> A C union does not allow that. Any C program that
      >> relies on it is non-portable.
      >>
      >> The following results are conforming to the C specification
      >> (note, this is a minor modification of a program posted
      >> elsewhere in the thread):
      >>
      >> #include <stdio.h>
      >>
      >> typedef union abc
      >> { int x;
      >> float y;
      >> } a_union;
      >>
      >> main()
      >> { a_union z;
      >>[/color]
      >
      > First example:[color=green]
      >> z.x = 1;
      >> printf("int val = %d\n", z.x);
      >> printf("float val = %f\n", z.y);
      >>[/color]
      >
      > Second example:[color=green]
      >> z.y = 3.142;
      >> printf("int val = %d\n", z.x);
      >> printf("float val = %f\n", z.y);
      >> return 0;
      >> }
      >>
      >> Results:
      >> int val = 1
      >> float val = 3.142
      >> int val = 1
      >> float val = 3.142[/color]
      >
      >
      > How does the mini-PI come out of a union (first example) that was
      > only set with integer 1?
      >
      > How does a 1 get pulled out of a union set with a value of mini-PI? A
      > /structure would do that at this point, since .x was set to 1, but
      > not a union.
      >
      > Unless I'm going nuts here (possible)...[/color]

      What I mean is, /unless the integer 1 representation happens to match a
      float's mini-PI's bit pattern/...



      --
      Framsticks. 3D Artificial Life evolution. You can see the creatures
      that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
      me). http://www.frams.alife.pl/


      Comment

      • CBFalconer

        #63
        Re: C to Java Byte Code

        Mark McIntyre wrote:[color=blue]
        >[/color]
        .... snip ...[color=blue]
        >
        > Marvellous. Since this has nothing to do with C any more, why the
        > heck are you stupidly crossposting this long and pointless thread
        > in CLC and CLC++. Go away.[/color]

        Not only that but some mentally challenged posters insist on
        restoring the mess when follow-ups have been set.

        --
        Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
        Available for consulting/temporary embedded and systems.
        <http://cbfalconer.home .att.net> USE worldnet address!


        Comment

        • Richard Herring

          #64
          Re: Welcome back Paul Lutus

          In message <clm9cj$d7e$1@n ntp1.jpl.nasa.g ov>, E. Robert Tisdale
          <E.Robert.Tisda le@jpl.nasa.gov > writes[color=blue]
          >Paul Lutus wrote:
          >
          >[snip]
          >
          >Hi Paul,
          >
          >Welcome back to the comp.lang.c and comp.lang.c++ newsgroups.
          >I checked Google newsgroups.
          >
          > http://groups.google.com/
          >
          >You've been absent from comp.lang.c++ since October 20, 2003
          >and absent from comp.lang.c since May 30,2002.
          >
          >No matter. Very little has changed since you've been gone. :-)[/color]


          Please don't trollishly crosspost between C and C++ groups. The outcome
          is rarely beneficial.
          --
          Richard Herring

          Comment

          • Richard Herring

            #65
            Re: C to Java Byte Code

            In message <10ntsg1o8vbi16 f@corp.supernew s.com>, Paul Lutus
            <nospam@nosite. zzz> writes[color=blue]
            >Mark McIntyre wrote:
            >[color=green]
            >> On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
            >> <nospam@nosite. zzz> wrote:
            >>[color=darkred]
            >>>Yes, it is a union in C, but I am saying it is not a union in the Java
            >>>bytecode.[/color]
            >>
            >> Marvellous. Since this has nothing to do with C any more,[/color]
            >
            >Do you see a reference to C in the sentence above? No? Is there an
            >optometrist available in your neighborhood?
            >
            >The discussion is about a C to Java cross-compiler. Both languages are
            >therefore topical.[/color]

            Not in comp.lang.c++, they are not. Please take this elsewhere.

            --
            Richard Herring

            Comment

            • Gerry Quinn

              #66
              Re: C to Java Byte Code

              In article <10nt68mmg3qtke 5@corp.supernew s.com>, nospam@nosite.z zz
              says...[color=blue]
              > Gerry Quinn wrote:[color=green]
              > >
              > > typedef union abc
              > > { int x;
              > > float y;
              > > } a_union;
              > >[color=darkred]
              > >> >> 2. This is not a union, it it two instances of the same variable.
              > >> >> Again, to reply to my post, you need to provide the Java bytecode that
              > >> >> unites a Java float and a Java integer in the same address space,
              > >> >> something that is not allowed in Java.[/color]
              > >
              > > Of course it's a union. It has two members x and y which are in this
              > > instance of different types, although that is by no means part of the
              > > specification.[/color]
              >
              > Yes, it is a union in C, but I am saying it is not a union in the Java
              > bytecode.[/color]

              How could it be a union in the Java bytecode? Java bytecode doesn't
              have unions, any more than machine code does. Unions are a feature of
              C. The compiler compiles bytecode from C source. The C source may
              contain unions. The bytecode doesn't, any more than a conventional
              executable would.
              [color=blue]
              > This intentional misquote unermines your entire post. My statement is[/color]

              There was no misquote.
              [color=blue]
              > clearly that, since Java doesn't support anything like a union, the product
              > doesn't create unions as its output, it can only read them from the C
              > source and then figure out what to do with them. What it produces in Java
              > bytecode is not a union. And, more to the point, what it does produce
              > behaves differently than the original C code does.[/color]

              No C compiler creates unions as its output. How could it? The target
              platforms, be they bytecode or machine code, don't have unions. What it
              produces behaves perfectly in accordance with the specifications of the
              C language.

              Your program even works quite well, except that it investigates data
              storage on the "C-emulation platform" that is created by the compiler.
              If the results surprise you, that is your problem. The C language
              specification does not say what will be investigated, or even promise
              that anything consistent will be. If you expect that the program should
              give identical results to a standard executable if the bytecode is run
              on the same platform, that expectation arises only because you don't
              understand C. Suppose another program measured the time to do a long
              calculation - would you expect the same result on that too? There is no
              difference.

              - Gerry Quinn








              Comment

              • Gerry Quinn

                #67
                Re: C to Java Byte Code

                In article <10ntspeg9d4mu0 5@corp.supernew s.com>, nospam@nosite.z zz
                says...[color=blue]
                > Willem wrote[color=green]
                > > Paul wrote:
                > > ) Yes, it is a union in C, but I am saying it is not a union in the Java
                > > ) bytecode.
                > >
                > > It doesnt *need* to be a union in the Java bytecode, you moron.[/color]
                >
                > The claim made by Mr. Abdullah is that unions are supported by his product.
                > Since unions are already supported in C, this can only mean his claim
                > refers to Java.[/color]

                That is just lunacy. His product is a C compiler, of sorts. It
                converts statements that reference unions consistently into bytecode.
                Therefore it supports unions.

                It supports unions in much the same way that (say) MSVC supports unions,
                by converting statements that reference unions consistently into object
                code.

                Neither object code nor bytecode have unions. Unions are a feature of
                C. Put C source containing unions into a compiler, turn the handle, and
                object code comes out that doesn't contain unions. It is *influenced*
                by the union declarations in the source code, but it contains no unions
                because unions do not exist in object code.

                - Gerry Quinn

                Comment

                • dandelion

                  #68
                  Re: C to Java Byte Code


                  "Gerry Quinn" <gerryq@DELETET HISindigo.ie> wrote in message
                  news:MPG.1be98d 72abdbb109989a6 7@news.indigo.i e...[color=blue]
                  > In article <10ntspeg9d4mu0 5@corp.supernew s.com>, nospam@nosite.z zz
                  > says...[color=green]
                  > > Willem wrote[color=darkred]
                  > > > Paul wrote:
                  > > > ) Yes, it is a union in C, but I am saying it is not a union in the[/color][/color][/color]
                  Java[color=blue][color=green][color=darkred]
                  > > > ) bytecode.
                  > > >
                  > > > It doesnt *need* to be a union in the Java bytecode, you moron.[/color]
                  > >
                  > > The claim made by Mr. Abdullah is that unions are supported by his[/color][/color]
                  product.[color=blue][color=green]
                  > > Since unions are already supported in C, this can only mean his claim
                  > > refers to Java.[/color]
                  >
                  > That is just lunacy. His product is a C compiler, of sorts. It
                  > converts statements that reference unions consistently into bytecode.
                  > Therefore it supports unions.
                  >
                  > It supports unions in much the same way that (say) MSVC supports unions,
                  > by converting statements that reference unions consistently into object
                  > code.
                  >
                  > Neither object code nor bytecode have unions. Unions are a feature of
                  > C. Put C source containing unions into a compiler, turn the handle, and
                  > object code comes out that doesn't contain unions. It is *influenced*
                  > by the union declarations in the source code, but it contains no unions
                  > because unions do not exist in object code.
                  >
                  > - Gerry Quinn[/color]

                  So if I read from a stream of data, I can overlay a set of nested
                  structs/unions in order to decypher the byte-array into a structured
                  message? As in the following?

                  typedef struct
                  {
                  uint8 inputs;
                  uint8 outputs;
                  uint8 timers;
                  } lc_statr_t;

                  typedef struct
                  {
                  uint8 errno;
                  char message[1];
                  } lc_error_t;

                  typedef struct
                  {
                  uint8 opcode;
                  uint8 sequence;
                  } lc_msg_header_t ;

                  typedef struct
                  {
                  lc_msg_header_t hdr;

                  union
                  {
                  lc_statr_t statr;
                  lc_error_t error;

                  uint8 cmd[LC_CMD_LEN]; /* placeholder */
                  char name[LC_NAME_LEN];
                  } data;
                  } lc_msg_t;

                  typedef struct
                  {
                  uint32 addr; /* originating ip_address */
                  uint16 port; /* originating port */
                  uint16 len; /* length of the packet */
                  } lc_packet_heade r_t;

                  typedef struct
                  {
                  lc_packet_heade r_t hdr;

                  union
                  {
                  lc_msg_t msg;
                  lc_tftp tftp;
                  char buffer[LC_BUFFERSIZE];
                  } u;
                  } lc_packet_t;

                  lc_packet_t.buf fer is read (recv) and I can use lc_packet_t.msg .hdr.opcode
                  to get at the opcode? Without actually moving *anything* in memory, of
                  course, since I don't have enough RAM available.


                  Comment

                  • Flash Gordon

                    #69
                    Re: C to Java Byte Code

                    On Wed, 27 Oct 2004 13:06:51 +0200
                    "dandelion" <dandelion@mead ow.net> wrote:

                    <snip unions>
                    [color=blue]
                    > So if I read from a stream of data, I can overlay a set of nested
                    > structs/unions in order to decypher the byte-array into a structured
                    > message? As in the following?
                    >
                    > typedef struct
                    > {
                    > uint8 inputs;[/color]

                    The compiler might insert padding here...
                    [color=blue]
                    > uint8 outputs;[/color]

                    or here...
                    [color=blue]
                    > uint8 timers;[/color]

                    or here.
                    [color=blue]
                    > } lc_statr_t;[/color]

                    Well, in C you might not have an 8 bit data type, which is presumably
                    what uint8 is...
                    [color=blue]
                    > typedef struct
                    > {
                    > uint8 errno;[/color]

                    The compiler might insert different padding here to that which it might
                    (or might not) have inserted in lc_statr_t
                    [color=blue]
                    > char message[1];
                    > } lc_error_t;
                    >
                    > typedef struct
                    > {
                    > uint8 opcode;
                    > uint8 sequence;
                    > } lc_msg_header_t ;[/color]

                    I believe that lc_msgs_header_ t is required to map correctly on to the
                    first 2 elements of lc_statr_t when they are combined in a union since
                    the first two elements are the same type.
                    [color=blue]
                    > typedef struct
                    > {
                    > lc_msg_header_t hdr;
                    >
                    > union
                    > {
                    > lc_statr_t statr;
                    > lc_error_t error;
                    >
                    > uint8 cmd[LC_CMD_LEN]; /* placeholder */
                    > char name[LC_NAME_LEN];
                    > } data;
                    > } lc_msg_t;
                    >
                    > typedef struct
                    > {
                    > uint32 addr; /* originating ip_address */
                    > uint16 port; /* originating port */
                    > uint16 len; /* length of the packet */
                    > } lc_packet_heade r_t;
                    >
                    > typedef struct
                    > {
                    > lc_packet_heade r_t hdr;
                    >
                    > union
                    > {
                    > lc_msg_t msg;
                    > lc_tftp tftp;
                    > char buffer[LC_BUFFERSIZE];
                    > } u;
                    > } lc_packet_t;
                    >
                    > lc_packet_t.buf fer is read (recv) and I can use
                    > lc_packet_t.msg .hdr.opcode to get at the opcode? Without actually
                    > moving *anything* in memory, of course, since I don't have enough RAM
                    > available.[/color]

                    *If* your compiler pads structs in the way your incoming data is padded
                    then I believe that you will get what you expect. However, version x.1
                    of your compiler might use different padding, and changing compiler
                    options might change the padding. So it is not a portable solution.
                    Also, if you had a double in there you would have a real danger of
                    reading a trap representation.

                    So if you want portable code you have to strip your message apart by
                    hand.
                    --
                    Flash Gordon
                    Sometimes I think shooting would be far too good for some people.
                    Although my email address says spam, it is real and I read it.

                    Comment

                    • Gerry Quinn

                      #70
                      Re: C to Java Byte Code

                      In article <417f814b$0$297 35$e4fe514c@dre ader14.news.xs4 all.nl>,
                      dandelion@meado w.net says...[color=blue]
                      > "Gerry Quinn" <gerryq@DELETET HISindigo.ie> wrote in message
                      > news:MPG.1be98d 72abdbb109989a6 7@news.indigo.i e...[/color]
                      [color=blue][color=green]
                      > > Neither object code nor bytecode have unions. Unions are a feature of
                      > > C. Put C source containing unions into a compiler, turn the handle, and
                      > > object code comes out that doesn't contain unions. It is *influenced*
                      > > by the union declarations in the source code, but it contains no unions
                      > > because unions do not exist in object code.[/color]
                      >
                      > So if I read from a stream of data, I can overlay a set of nested
                      > structs/unions in order to decypher the byte-array into a structured
                      > message? As in the following?
                      >
                      > typedef struct
                      > {
                      > uint8 inputs;
                      > uint8 outputs;
                      > uint8 timers;
                      > } lc_statr_t;[/color]

                      [etc.]
                      [color=blue]
                      > lc_packet_t.buf fer is read (recv) and I can use lc_packet_t.msg .hdr.opcode
                      > to get at the opcode? Without actually moving *anything* in memory, of
                      > course, since I don't have enough RAM available.[/color]

                      I don't see why not, so long as you have reason to believe that the
                      conversion of disparate types within a union (undefined in C) is
                      consistent for a given implementation [seems to be in this case, and
                      probably would be on most conventional hardware], that the storage of
                      relevant data types does not appear as padding in the storage of others
                      [you will want to check on that, I think], and that you are capable of
                      identifying the opcode corresponding to the reinterpretatio n of one or
                      more chars or part of chars into whatever you have defined as uint8.

                      I recommend, however, that you do not rely so heavily on undefined
                      behaviour. If you intend to read a series of chars, it would be a good
                      idea to define your opcodes or whatever in terms of chars. Then you
                      need have no fears that your code will give unpredictable results on
                      different implementations .

                      - Gerry Quinn





                      Comment

                      • dandelion

                        #71
                        Re: C to Java Byte Code


                        "Gerry Quinn" <gerryq@DELETET HISindigo.ie> wrote in message
                        news:MPG.1be9ae dec47a2bd4989a6 b@news.indigo.i e...[color=blue]
                        > In article <417f814b$0$297 35$e4fe514c@dre ader14.news.xs4 all.nl>,
                        > dandelion@meado w.net says...[color=green]
                        > > "Gerry Quinn" <gerryq@DELETET HISindigo.ie> wrote in message
                        > > news:MPG.1be98d 72abdbb109989a6 7@news.indigo.i e...[/color]
                        >[color=green][color=darkred]
                        > > > Neither object code nor bytecode have unions. Unions are a feature of
                        > > > C. Put C source containing unions into a compiler, turn the handle,[/color][/color][/color]
                        and[color=blue][color=green][color=darkred]
                        > > > object code comes out that doesn't contain unions. It is *influenced*
                        > > > by the union declarations in the source code, but it contains no[/color][/color][/color]
                        unions[color=blue][color=green][color=darkred]
                        > > > because unions do not exist in object code.[/color]
                        > >
                        > > So if I read from a stream of data, I can overlay a set of nested
                        > > structs/unions in order to decypher the byte-array into a structured
                        > > message? As in the following?
                        > >
                        > > typedef struct
                        > > {
                        > > uint8 inputs;
                        > > uint8 outputs;
                        > > uint8 timers;
                        > > } lc_statr_t;[/color]
                        >
                        > [etc.]
                        >[color=green]
                        > > lc_packet_t.buf fer is read (recv) and I can use[/color][/color]
                        lc_packet_t.msg .hdr.opcode[color=blue][color=green]
                        > > to get at the opcode? Without actually moving *anything* in memory, of
                        > > course, since I don't have enough RAM available.[/color]
                        >
                        > I don't see why not, so long as you have reason to believe that the
                        > conversion of disparate types within a union (undefined in C) is
                        > consistent for a given implementation [seems to be in this case, and
                        > probably would be on most conventional hardware], that the storage of
                        > relevant data types does not appear as padding in the storage of others
                        > [you will want to check on that, I think],[/color]

                        I checked. I'm on an 8 bit platform, so padding isn't an issue.
                        [color=blue]
                        > and that you are capable of
                        > identifying the opcode corresponding to the reinterpretatio n of one or
                        > more chars or part of chars into whatever you have defined as uint8.[/color]

                        typedef unsigned char uint8;
                        [color=blue]
                        > I recommend, however, that you do not rely so heavily on undefined
                        > behaviour.[/color]

                        Which undefined behavior? If you knew the compiler i'm using, you'd
                        (probably) laugh your arse off thinking of "undefined behavior". It is
                        (putting it mildly) not very conforming. In fact, it isn't even C, just
                        (vaguely) C-like. However, the structure as presented in my previous post is
                        what's running (more or less) on the host aswell. Although padding *is* an
                        issue (a tackled one) there.
                        [color=blue]
                        > If you intend to read a series of chars, it would be a good
                        > idea to define your opcodes or whatever in terms of chars.[/color]

                        I intend to read a structured message coming in from a UDP connection
                        and/or a RS485 serial line (allthough the latter uses a slightly different
                        definition on the lowest level). So, no... There's no naked 'char' in sight,
                        only a number of 8-bit values (in order to avoid endianness issues). That's
                        why I defined everything using uint8 (which is typedeffed as an unsigned
                        char). The chances of any of the uint8's mentioned containing anything
                        printable is not very big.
                        [color=blue]
                        > Then you
                        > need have no fears that your code will give unpredictable results on
                        > different implementations .[/color]

                        Does the 'Byte-code compiler' of the OP move memory or not? As previously
                        mentioned, the intended platform is a micro-controller in an embedded
                        environment.


                        Comment

                        • dandelion

                          #72
                          Re: C to Java Byte Code


                          "dandelion" <dandelion@mead ow.net> wrote in message news:417fadf9$0 $148

                          Question restracted. Thanks for the cooperation.


                          Comment

                          • Alfred Z. Newmane

                            #73
                            Re: C to Java Byte Code

                            Flash Gordon wrote:[color=blue]
                            > On Wed, 27 Oct 2004 13:06:51 +0200
                            > "dandelion" <dandelion@mead ow.net> wrote:
                            >
                            > <snip unions>
                            >[color=green]
                            >> So if I read from a stream of data, I can overlay a set of nested
                            >> structs/unions in order to decypher the byte-array into a structured
                            >> message? As in the following?
                            >>
                            >> typedef struct
                            >> {
                            >> uint8 inputs;[/color]
                            >
                            > The compiler might insert padding here...
                            >[color=green]
                            >> uint8 outputs;[/color]
                            >
                            > or here...
                            >[color=green]
                            >> uint8 timers;[/color]
                            >
                            > or here.
                            >[color=green]
                            >> } lc_statr_t;[/color]
                            >
                            > Well, in C you might not have an 8 bit data type, which is presumably
                            > what uint8 is...
                            >[color=green]
                            >> typedef struct
                            >> {
                            >> uint8 errno;[/color]
                            >
                            > The compiler might insert different padding here to that which it
                            > might (or might not) have inserted in lc_statr_t
                            >[color=green]
                            >> char message[1];
                            >> } lc_error_t;
                            >>
                            >> typedef struct
                            >> {
                            >> uint8 opcode;
                            >> uint8 sequence;
                            >> } lc_msg_header_t ;[/color]
                            >
                            > I believe that lc_msgs_header_ t is required to map correctly on to the
                            > first 2 elements of lc_statr_t when they are combined in a union since
                            > the first two elements are the same type.
                            >[color=green]
                            >> typedef struct
                            >> {
                            >> lc_msg_header_t hdr;
                            >>
                            >> union
                            >> {
                            >> lc_statr_t statr;
                            >> lc_error_t error;
                            >>
                            >> uint8 cmd[LC_CMD_LEN]; /* placeholder */
                            >> char name[LC_NAME_LEN];
                            >> } data;
                            >> } lc_msg_t;
                            >>
                            >> typedef struct
                            >> {
                            >> uint32 addr; /* originating ip_address */
                            >> uint16 port; /* originating port */
                            >> uint16 len; /* length of the packet */
                            >> } lc_packet_heade r_t;
                            >>
                            >> typedef struct
                            >> {
                            >> lc_packet_heade r_t hdr;
                            >>
                            >> union
                            >> {
                            >> lc_msg_t msg;
                            >> lc_tftp tftp;
                            >> char buffer[LC_BUFFERSIZE];
                            >> } u;
                            >> } lc_packet_t;
                            >>
                            >> lc_packet_t.buf fer is read (recv) and I can use
                            >> lc_packet_t.msg .hdr.opcode to get at the opcode? Without actually
                            >> moving *anything* in memory, of course, since I don't have enough RAM
                            >> available.[/color]
                            >
                            > *If* your compiler pads structs in the way your incoming data is
                            > padded then I believe that you will get what you expect. However,
                            > version x.1 of your compiler might use different padding, and
                            > changing compiler options might change the padding. So it is not a
                            > portable solution. Also, if you had a double in there you would have
                            > a real danger of reading a trap representation.
                            >
                            > So if you want portable code you have to strip your message apart by
                            > hand.[/color]

                            You cna use pragmas or other means to force a specific byte alignment,
                            can you not? If it was distributed code, it would most like be
                            documented (and commented in the code) reguarding that.


                            Comment

                            • Gerry Quinn

                              #74
                              Re: C to Java Byte Code

                              In article <10ntt7tjecg301 e@corp.supernew s.com>, nospam@nosite.z zz
                              says...[color=blue]
                              >
                              > http://explanation-guide.info/meanin...age-union.html
                              >
                              > "Because they occupy the same space, changing u.a also changes the value of
                              > u.b."
                              >
                              > "The primary usefulness of a union is to conserve space, since it provides a
                              > way of letting many different types be stored in the same space."[/color]

                              And:

                              "The meaning of the new value of u.b is implementation dependent, and in
                              fact the C Standard states that it is invalid to read u.b if u.a was
                              last written."

                              - Gerry Quinn

                              Comment

                              • Galga

                                #75
                                Re: C to Java Byte Code

                                Richard Herring wrote:[color=blue]
                                > In message <10ntsg1o8vbi16 f@corp.supernew s.com>, Paul Lutus
                                > <nospam@nosite. zzz> writes[color=green]
                                >> Mark McIntyre wrote:
                                >>[color=darkred]
                                >>> On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
                                >>> <nospam@nosite. zzz> wrote:
                                >>>
                                >>>> Yes, it is a union in C, but I am saying it is not a union in the
                                >>>> Java bytecode.
                                >>>
                                >>> Marvellous. Since this has nothing to do with C any more,[/color]
                                >>
                                >> Do you see a reference to C in the sentence above? No? Is there an
                                >> optometrist available in your neighborhood?
                                >>
                                >> The discussion is about a C to Java cross-compiler. Both languages
                                >> are therefore topical.[/color]
                                >
                                > Not in comp.lang.c++, they are not. Please take this elsewhere.
                                >
                                > --
                                > Richard Herring[/color]


                                Richard, is it going to warp the the fecking space time continuum to get
                                off your high horse about a topic that is just maybe mere ounces off
                                topic?

                                In case you haven't noticed, C and even Java are related languages; many
                                who use one use or have experience with the others, and who are you to
                                speak for everyone in c.l.c++, when it might be of interest of people
                                there? Actually many people I've seen post there have taken interest in
                                this thread, so I think you are proven wrong just by that.

                                If you don't like a thread, then kill it on your end, please don't try
                                to push your tastes on other people; even though this thread may not be
                                100% topical, but it still can have a place in any of the groups listed.

                                In fact, this was the entire point of cross posted, as par a gigantic
                                thread a couple years ago about cross posting; ultimately it's to bring
                                people of similar interests together, and this topic is just that and
                                has DONE just that.

                                So again, kindly kill file this thread if you don't want to see it.

                                ~Galga


                                Comment

                                Working...