Professional Web Applications Themes

strtof() weird behaviour - Mac Programming

Peter Ammon wrote:  >> >> >> by default gcc does not require prototypes, which is why it compiles >>  >> >> and also why it goes pearshaped. The default return type for a >> function is int, so strtof returns 4 bytes worth of float (or 8 >> bytes worth of double in the case of strtod) but the compiler is >> handling them as 4 bytes of int.[/ref] > > Probably true on x86, but not on the PowerPC. Floating point types > are returned in floating point registers, integral types returned in > GPRs, so the value returned ...

  1. #1

    Default Re: strtof() weird behaviour

    Peter Ammon wrote: 
    >>
    >>
    >> by default gcc does not require prototypes, which is why it compiles
    >> 
    >>
    >> and also why it goes pearshaped. The default return type for a
    >> function is int, so strtof returns 4 bytes worth of float (or 8
    >> bytes worth of double in the case of strtod) but the compiler is
    >> handling them as 4 bytes of int.[/ref]
    >
    > Probably true on x86, but not on the PowerPC. Floating point types
    > are returned in floating point registers, integral types returned in
    > GPRs, so the value returned bears no relation to the expected value.
    > For example, this is likely to work on x86 but not on PowerPC:
    >
    > int main(void) {
    > int i = strtof("123.4", 0);
    > float f = *(float*)&i;
    > printf("%f\n", f);
    > return 0;
    > }
    >
    > [...][/ref]

    OUCH!! I think you may have solved my problem. Did the old Motorola 68030
    series suffer from this same problem??


    GreyCloud Guest

  2. #2

    Default Re: strtof() weird behaviour

    In article <q9Eac.16921$news.prodigy.com>,
    Peter Ammon <com> wrote:
     
    > >
    > >
    > > by default gcc does not require prototypes, which is why it compiles
    > > 
    > >
    > > and also why it goes pearshaped. The default return type for a function is
    > > int, so strtof returns 4 bytes worth of float (or 8 bytes worth of double
    > > in the case of strtod) but the compiler is handling them as 4 bytes of
    > > int.[/ref]
    >
    > Probably true on x86, but not on the PowerPC. Floating point types are
    > returned in floating point registers, integral types returned in GPRs,
    > so the value returned bears no relation to the expected value. For
    > example, this is likely to work on x86 but not on PowerPC:
    >
    > int main(void) {
    > int i = strtof("123.4", 0);
    > float f = *(float*)&i;
    > printf("%f\n", f);
    > return 0;
    > }[/ref]

    This one isn't going to work on any architecture in which ints have a
    different representation in memory than floats, which probably covers
    every architecture that supports floating point numbers. The *(float *)
    &i line says "Take the address of i, treat that address as a pointer to
    a float, and read the contents of memory at that address as if they're a
    float." That'll only work correctly if memory at that address actually
    contains a representation of a floating point number.

    -Eric

    --
    Eric Albert stanford.edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  3. #3

    Default Re: strtof() weird behaviour

    GreyCloud <com> wrote: [/ref]

    Nope, as someone else has pointed out this won't give a happy result on
    x86 or any other architecture since floats and ints have different binary
    representations. It has very little, if any, to do with returning floats
    in registers versus a stack. However, a very similar example would rely
    on a little-endian processor to function as one might naively expect:

    int main(void) {
    int i = 12;
    short n = *(short*)&i;
    printf("%hd\n",n);
    }

    This produces 0 on a big-endian machine and 12 on a little-endian machine.
    Either result is correct, since the code just prints the first two bytes of
    i as a short. Any judgement one might make as to whether these two bytes
    are necessarily the most significant or the least significant is an error
    of endian-specific assumption.
     

    I think it's fair to say that if your code is doing anything like this, then
    there's no problem with the architecture, only the improperly written code :).

    -- Erick
    Erick Guest

Similar Threads

  1. Weird ssh behaviour with 5.2
    By snogfest in forum AIX
    Replies: 6
    Last Post: January 13th, 07:11 PM
  2. Weird Behaviour Bug...anyone?
    By Richard in forum Macromedia Director Lingo
    Replies: 2
    Last Post: January 5th, 05:21 PM
  3. Weird Variable Behaviour
    By Jerz in forum PHP Development
    Replies: 0
    Last Post: July 31st, 09:46 AM
  4. Access weird behaviour?
    By speederpro in forum Microsoft Access
    Replies: 1
    Last Post: July 15th, 10:08 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139