Re: Unexpected truncation behavior

Discussion in 'C Programming' started by glen herrmannsfeldt, Jun 28, 2013.

  1. Giuseppe <> wrote:

    > I tried to understand why I can't get the message:


    > "r1 is 10, r2 is 10"


    > as result from the code below when I compile it with
    > gcc4.8.1 *on Windows*. What I get is:


    > "r1 is 10, r2 is 9"


    > instead. Any other compiler and gcc on Linux display the
    > expected message. Wouldn't the C language "require" the
    > result to be the one I expect?


    C is slightly more restrictive than Fortran on what is allowed
    with floating point, but no.

    Assuming your system uses binary floating point (which except
    for some IBM systems is pretty much guaranteed) then the rounding
    for decimal values that aren't exact binary fractions can easily
    round down to 9.

    There are so many articles around on the inexactness of binary
    floating point representations of decimal fractions, you should
    find one and read it.

    > #include <stdio.h>
    > int main(void)
    > {
    > float a = 3.3f, b = 3.3f, c = 3.4f;
    > double d = 3.3, e = 3.3, f = 3.4;
    > int r1, r2;
    > r1 = a + b + c;
    > r2 = d + e + f;
    > printf("r1 is %d, r2 is %d\n", r1, r2);
    > return 0;
    > }


    -- glen
     
    glen herrmannsfeldt, Jun 28, 2013
    #1
    1. Advertising

  2. glen herrmannsfeldt

    BartC Guest

    "Giuseppe" <> wrote in message
    news:...
    > Il 28/06/2013 12:00, glen herrmannsfeldt ha scritto:


    >> Assuming your system uses binary floating point (which except
    >> for some IBM systems is pretty much guaranteed) then the rounding
    >> for decimal values that aren't exact binary fractions can easily
    >> round down to 9.


    > Thanks, I understand that, but it happens that when I print "d+e+f"
    > with "printf("d + e + f is %f\n", d + e + f);" it displays 10.000000
    > as expected. What I don't understand is why "r2 = d + e + f;" does not
    > truncate that number to 10 and gives me 9 instead. This is what I mean:


    You can't tell what's going to happen with floating point. If the actual
    result is 9.999999999999999xxx, then it's possible that %f to the default
    number of decimals will round up to 10.0, while conversion to int will
    always round down.

    You should use a rounding function when converting to int if that is what
    you want. I can't remember what it is off-hand, but just adding 0.5 to a
    floating point result before assigning to an int might do the trick for
    positive values (however you will need the proper function).

    --
    Bartc
     
    BartC, Jun 28, 2013
    #2
    1. Advertising

  3. In article <>,
    Giuseppe <> wrote:
    >Il 28/06/2013 12:54, Giuseppe ha scritto:
    >
    >> Thanks David Brown and BartC, this makes even more sense to me.
    >> I was not aware of a possible difference in rounding with %f and
    >> truncation in assignments to integer types.
    >>

    >
    >I still have some doubts about why this behavior is only related
    >to gcc on windows. The same compiler on Linux doesn't show the same
    >behavior, nor do other compilers on both Windows and Linux.
    >I'm not saying that operations between floating point numbers should
    >lead to exact results, what I'm surprised of is the inconsistent
    >behaviors for the same compiler on the same architecture on two different
    >operating systems.


    The stock clc answer is: It doesn't matter what happens. Anything can
    happen. It is just as likely to depend on the phase of the moon as it is
    to depend on the OS or the compiler in use.

    As far as I can tell, C is perfectly free to report the result of:

    2.1 + 3.4

    as

    9.76

    --

    Some of the more common characteristics of Asperger syndrome include:

    * Inability to think in abstract ways (eg: puns, jokes, sarcasm, etc)
    * Difficulties in empathising with others
    * Problems with understanding another person's point of view
    * Hampered conversational ability
    * Problems with controlling feelings such as anger, depression
    and anxiety
    * Adherence to routines and schedules, and stress if expected routine
    is disrupted
    * Inability to manage appropriate social conduct
    * Delayed understanding of sexual codes of conduct
    * A narrow field of interests. For example a person with Asperger
    syndrome may focus on learning all there is to know about
    baseball statistics, politics or television shows.
    * Anger and aggression when things do not happen as they want
    * Sensitivity to criticism
    * Eccentricity
    * Behaviour varies from mildly unusual to quite aggressive
    and difficult
     
    Kenny McCormack, Jun 28, 2013
    #3
  4. glen herrmannsfeldt

    BartC Guest

    "Giuseppe" <> wrote in message
    news:...
    > Il 28/06/2013 13:11, Kenny McCormack ha scritto:
    >
    >>
    >> The stock clc answer is: It doesn't matter what happens. Anything can
    >> happen. It is just as likely to depend on the phase of the moon as it is
    >> to depend on the OS or the compiler in use.
    >>
    >> As far as I can tell, C is perfectly free to report the result of:
    >>
    >> 2.1 + 3.4
    >>
    >> as
    >>
    >> 9.76
    >>

    >
    > So you are saying that we cannot do calculations with the C language?


    I don't think he was being serious.

    Adding 2.1 to 3.4 will give a result of approximately 5.5, but it might be
    anything from 5.49999999999xxxx to 5.50000000000xxxx. It's this that you
    need to bear in mind. Also that printf() can round values so it will appear
    as though the result is 5.50000000 exactly.

    --
    Bartc
     
    BartC, Jun 28, 2013
    #4
  5. In article <vtezt.3355$4>, BartC <> wrote:
    ....
    >I don't think he was being serious.


    Well, semi-serious.

    I was making the point that if some inaccuracy is allowed, then how do we
    know how much is allowed? I mean, 9.76 is actually pretty close to the right
    answer. It's off by less than 5, which is a pretty small epsilon in the
    grand scheme of things.

    >Adding 2.1 to 3.4 will give a result of approximately 5.5, but it might be
    >anything from 5.49999999999xxxx to 5.50000000000xxxx. It's this that you
    >need to bear in mind. Also that printf() can round values so it will appear
    >as though the result is 5.50000000 exactly.


    Really? Really between 5.49999999999xxxx and 5.50000000000xxxx?

    C & V, please?

    --
    Is God willing to prevent evil, but not able? Then he is not omnipotent.
    Is he able, but not willing? Then he is malevolent.
    Is he both able and willing? Then whence cometh evil?
    Is he neither able nor willing? Then why call him God?
    ~ Epicurus
     
    Kenny McCormack, Jun 28, 2013
    #5
  6. On 28.06.2013 13:30, BartC wrote:

    >>> As far as I can tell, C is perfectly free to report the result of:
    >>>
    >>> 2.1 + 3.4
    >>>
    >>> as
    >>>
    >>> 9.76

    >>
    >> So you are saying that we cannot do calculations with the C language?

    >
    > I don't think he was being serious.


    Actually he makes a very good point. If the standard answer is "well
    that's just some floating-point artifact", then the question arises: How
    bad may a floating-point implementation behave while still conforming to
    the standard? Would his FP implementation that results 2.1 + 3.4 = 9.76
    be standard compliant or not?

    Regards,
    Johannes

    --
    >> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

    > Zumindest nicht öffentlich!

    Ah, der neueste und bis heute genialste Streich unsere großen
    Kosmologen: Die Geheim-Vorhersage.
    - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>
     
    Johannes Bauer, Jun 28, 2013
    #6
  7. glen herrmannsfeldt

    Ken Brody Guest

    On 6/28/2013 7:39 AM, Kenny McCormack wrote:
    > In article <vtezt.3355$4>, BartC <> wrote:
    > ...
    >> I don't think he was being serious.

    >
    > Well, semi-serious.
    >
    > I was making the point that if some inaccuracy is allowed, then how do we
    > know how much is allowed? I mean, 9.76 is actually pretty close to the right
    > answer. It's off by less than 5, which is a pretty small epsilon in the
    > grand scheme of things.
    >
    >> Adding 2.1 to 3.4 will give a result of approximately 5.5, but it might be
    >> anything from 5.49999999999xxxx to 5.50000000000xxxx. It's this that you
    >> need to bear in mind. Also that printf() can round values so it will appear
    >> as though the result is 5.50000000 exactly.

    >
    > Really? Really between 5.49999999999xxxx and 5.50000000000xxxx?
    >
    > C & V, please?


    He said "might be", not "is", or even "is probably".
     
    Ken Brody, Jun 28, 2013
    #7
  8. glen herrmannsfeldt

    Ken Brody Guest

    On 6/28/2013 7:42 AM, Giuseppe wrote:
    > Il 28/06/2013 13:30, BartC ha scritto:

    [...]
    >> Adding 2.1 to 3.4 will give a result of approximately 5.5, but it might
    >> be anything from 5.49999999999xxxx to 5.50000000000xxxx. It's this that
    >> you need to bear in mind. Also that printf() can round values so it will
    >> appear as though the result is 5.50000000 exactly.
    >>

    > Thanks, now it's clear. I tried with 3 compilers on both
    > operating systems, I was probably surprised to see how the
    > same compiler can behave differently. Thanks again.


    If you change all of the "%f" specifiers in your printf's with "%.20f", you
    may see a very subtle difference in the representation of the numbers.
     
    Ken Brody, Jun 28, 2013
    #8
  9. In article <>,
    Lowell Gilbert <> wrote:
    ....
    >"IEEE floating point") as well as the C standard, so although such
    >a bogus implementation could exist, it doesn't.


    That's not a CLC-compliant posting.

    Besides, I wrote one (a standards compliant implementation) just last
    night. And it generates 9.76 as the answer.

    --
    Those on the right constantly remind us that America is not a
    democracy; now they claim that Obama is a threat to democracy.
     
    Kenny McCormack, Jun 28, 2013
    #9
  10. glen herrmannsfeldt

    Tim Prince Guest

    On 6/28/2013 10:08 AM, Giuseppe wrote:
    > Il 28/06/2013 15:54, Ken Brody ha scritto:
    >> On 6/28/2013 7:42 AM, Giuseppe wrote:
    >>> Il 28/06/2013 13:30, BartC ha scritto:

    >> [...]
    >>>> Adding 2.1 to 3.4 will give a result of approximately 5.5, but it might
    >>>> be anything from 5.49999999999xxxx to 5.50000000000xxxx. It's this that
    >>>> you need to bear in mind. Also that printf() can round values so it
    >>>> will
    >>>> appear as though the result is 5.50000000 exactly.
    >>>>
    >>> Thanks, now it's clear. I tried with 3 compilers on both
    >>> operating systems, I was probably surprised to see how the
    >>> same compiler can behave differently. Thanks again.

    >>
    >> If you change all of the "%f" specifiers in your printf's with "%.20f",
    >> you may see a very subtle difference in the representation of the
    >> numbers.

    >
    > Yes, I'm aware of this, thanks anyway. What confused me was that
    > in this code:
    >
    > #include <stdio.h>
    > int main(void)
    > {
    > float a = 3.3f, b = 3.3f, c = 3.4f;
    > double d = 3.3, e = 3.3, f = 3.4;
    > int r1, r2;
    > r1 = a + b + c;
    > r2 = d + e + f;
    > printf("d = %f e = %f f = %f\n", d, e, f);
    > printf("d + e + f is %f\n", d + e + f);
    > printf("r1 is %d, r2 is %d\n", r1, r2);
    > return 0;
    > }
    >
    > no matter how "d + e + f" is approximated, when it is assigned to r2 it's
    > not truncated the same way by the same compiler (gcc 4.8.1) on windows
    > and linux. In the former case r2 is 9 and the latter r2 is 10.
    >

    Presumably, you used different -march options (or defaults for those).
    Default for gcc 32-bit (i486) remains to use 387. If you showed the
    screen echos with -v, you've strung out this threads so far I couldn't
    find them.

    --
    Tim Prince
     
    Tim Prince, Jun 28, 2013
    #10
  11. On 28.06.2013 16:00, Lowell Gilbert wrote:

    > Compliant with the C standard, theoretically yes. The arithmetic
    > operations (+-*/) are left as implementation-defined. But most
    > implementations adhere to a floating point standard (most commonly
    > "IEEE floating point") as well as the C standard, so although such
    > a bogus implementation could exist, it doesn't.


    So then if an implementation chooses to use the FPU aseembly
    instructions the instruction set provides and hardware implmentations
    differ (for example, the Pentium bug, rounding differences between
    Intel/AMD) does this mean that floating point operations are undefined
    behavior?

    Regards,
    Johannes

    --
    >> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

    > Zumindest nicht öffentlich!

    Ah, der neueste und bis heute genialste Streich unsere großen
    Kosmologen: Die Geheim-Vorhersage.
    - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>
     
    Johannes Bauer, Jun 28, 2013
    #11
  12. Johannes Bauer <> writes:

    > On 28.06.2013 16:00, Lowell Gilbert wrote:
    >
    >> Compliant with the C standard, theoretically yes. The arithmetic
    >> operations (+-*/) are left as implementation-defined. But most
    >> implementations adhere to a floating point standard (most commonly
    >> "IEEE floating point") as well as the C standard, so although such
    >> a bogus implementation could exist, it doesn't.

    >
    > So then if an implementation chooses to use the FPU aseembly
    > instructions the instruction set provides and hardware implmentations
    > differ (for example, the Pentium bug, rounding differences between
    > Intel/AMD) does this mean that floating point operations are undefined
    > behavior?


    No. "Whatever the FPU puts out on this hardware" *is* defining the
    operations, as far as the C language is concerned. If it's not
    detailed enough for your particular purpose, you might consider
    that a quality of implementation issue, but implementation-defined
    is different than undefined.

    --
    Lowell Gilbert, embedded/networking software engineer
    http://be-well.ilk.org/~lowell/
     
    Lowell Gilbert, Jun 28, 2013
    #12
  13. glen herrmannsfeldt

    BartC Guest

    "Kenny McCormack" <> wrote in message
    news:kqjsl0$s5$...
    > In article <vtezt.3355$4>, BartC <> wrote:


    >>Adding 2.1 to 3.4 will give a result of approximately 5.5, but it might be
    >>anything from 5.49999999999xxxx to 5.50000000000xxxx. It's this that you
    >>need to bear in mind. Also that printf() can round values so it will
    >>appear
    >>as though the result is 5.50000000 exactly.

    >
    > Really? Really between 5.49999999999xxxx and 5.50000000000xxxx?
    >
    > C & V, please?


    Those values were obtained by holding down the relevant key until I got
    enough 9s and 0s that I thought would make the point. Then one was trimmed
    so that they tidily matched in number.

    This is a typical pattern you might expect using binary floating point in a
    language. If it gives anything like 9.76, then you need a new computer or a
    better implementation.

    (As it happens, the errors in representing 2.1 and 3.4 seem to cancel each
    other out in my computer, at least, according to my printf(). So that the
    calculation performed is apparently 2.0999999046325684 + 3.4000000953674316
    for float, and 2.1000000000000001 + 3.3999999999999999 for double, both
    giving exactly 5.5.)

    --
    Bartc
     
    BartC, Jun 28, 2013
    #13
  14. glen herrmannsfeldt

    James Kuyper Guest

    On 06/28/2013 07:04 AM, Giuseppe wrote:
    > Il 28/06/2013 12:54, Giuseppe ha scritto:
    >
    >> Thanks David Brown and BartC, this makes even more sense to me.
    >> I was not aware of a possible difference in rounding with %f and
    >> truncation in assignments to integer types.
    >>

    >
    > I still have some doubts about why this behavior is only related
    > to gcc on windows. The same compiler on Linux doesn't show the same
    > behavior, nor do other compilers on both Windows and Linux.


    The fundamental problem is not related to Windows, gcc, or even the C
    language. It's a fundamental property of floating point math. Different
    compilers for different languages on different machines will show
    symptoms of the problem under different circumstances, and you were
    unlucky enough to test the program on several systems where the problem
    did not come up. However, if you try a sufficiently large variety of
    different numbers, you'll find a set that doesn't add up properly, no
    matter with platform, compiler, or language you're using.

    > I'm not saying that operations between floating point numbers should
    > lead to exact results, what I'm surprised of is the inconsistent
    > behaviors for the same compiler on the same architecture on two different
    > operating systems.


    I've no idea why it would be different, but I'm not surprised that it
    is. You might want to take a look at the generated assembly language to
    find out what it does differently on the two different operating systems.
    --
    James Kuyper
     
    James Kuyper, Jun 28, 2013
    #14
  15. glen herrmannsfeldt

    James Kuyper Guest

    On 06/28/2013 07:14 AM, Giuseppe wrote:
    > Il 28/06/2013 13:11, Kenny McCormack ha scritto:
    >
    >>
    >> The stock clc answer is: It doesn't matter what happens. Anything can
    >> happen. It is just as likely to depend on the phase of the moon as it is
    >> to depend on the OS or the compiler in use.
    >>
    >> As far as I can tell, C is perfectly free to report the result of:
    >>
    >> 2.1 + 3.4
    >>
    >> as
    >>
    >> 9.76

    >
    > So you are saying that we cannot do calculations with the C language?


    The C standard explicitly says that "The accuracy of the floating-point
    operations (+, -, *, /) and of the library functions in <math.h> and
    <complex.h> that return floating-point results is implementation
    defined, as is the accuracy of the conversion between floating-point
    internal representations and string representations performed by the
    library functions in <stdio.h>, <stdlib.h>, and <wchar.h>. The
    implementation may state that the accuracy is unknown." (5.2.4.2.2p6)

    If that were the only relevant statement in the C standard, C floating
    point math would, in principle, be completely unusable. A fully
    conforming implementation of C could, in principle, implement floating
    point subtraction with sufficiently low accuracy that 0-0 > DBL_MAX. In
    practice, most implementations of C implement floating point math with
    reasonable accuracy - that's because the implementors don't want to lose
    your business - it's not because the C standard requires it.

    However, C99 allows the implementation to pre-#define the macro
    __STDC_IEC_559__. If it chooses to do so, then it is required to conform
    to the additional requirements of Annex K. That is almost (but not
    quite) the same as requiring that the implementation conform to IEC
    60559, which is equivalent to IEEE 754. If that's the case, the accuracy
    requirements are pretty much as strict as they can reasonably be
    expected to be.

    Even #if __STDC_IEC_559__, you still won't avoid the problems described
    in the Goldberg paper that Mark Bluemel referred you to. Those problems
    cannot be avoided, they can only be acknowledged and dealt with. If
    accuracy of floating point math matters to you, reading that paper is
    essential.
    --
    James Kuyper
     
    James Kuyper, Jun 28, 2013
    #15
  16. Giuseppe <> wrote:
    > Il 28/06/2013 16:16, Tim Prince ha scritto:


    (snip)
    >> Presumably, you used different -march options (or defaults for those).
    >> Default for gcc 32-bit (i486) remains to use 387. If you showed the
    >> screen echos with -v, you've strung out this threads so far I couldn't
    >> find them.


    > I just tried again and this is what happens: the build of gcc I have on
    > Windows doesn't optimize code by default. I have to enable -O1 at least
    > to get r2==10 instead of 9. On Linux I get directly r2==10 and only get
    > r2==9 if I disable optimizations with -O0.


    There is an additional complication that some compilers do
    arithmetic of compile time constants different than they do
    at run time with variables.

    Personally, I don't find it especially useful, but it is true.

    One favorite example, in the days of the Pentium FDIV bug
    there were programs written to detect it using constant
    expressions. Some compilers did a software emulation of the
    binary IEEE floating point, and avoided the FDIV instructions.

    More recently, there are compilers that will do arbitrary precision
    arithmetic on compile time expressions.

    As for the OP, the binary fraction rounds down about half the time
    and up about half the time, rounding at a different bit for float
    and double. Given two different constants, there is about a 1 in
    four chance that both round down.

    -- glen
     
    glen herrmannsfeldt, Jun 28, 2013
    #16
  17. Giuseppe <> wrote:

    (snip, someone wrote)
    >> I've no idea why it would be different, but I'm not surprised that it
    >> is. You might want to take a look at the generated assembly language to
    >> find out what it does differently on the two different operating systems.


    > Indeed that's what I've done and I've found that compiling with
    > optimizations enabled on Windows will display the value 10 instead of 9
    > for r2, which is closer to what one would expect in exact arithmetics.
    > The assembly generated shows that the optimized code generated the
    > instruction "CVTTSD2SI" (it belongs to the SSE2 set):


    The x87 instructions use 80 bit registers with a 64 bit significand,
    while SSE2, I believe, uses 64 bits for double with a 53 bit
    significand.

    With SSE2, it will round to 53 bits after each add, while x87
    will keep the full sum and round at the end. In addition, as
    previously noted, the decimal values are rounded up or down
    to the appropriate (usually nearest) binary value.

    (snip required by my posting host)

    > Such optimization is enabled by default on Linux. So in order to get
    > a more accurate result, an extra instruction needs to be generated.
    > Thank you.


    Note that in your case, fewer bits might give what you call a more
    accurate result.

    -- glen
     
    glen herrmannsfeldt, Jun 28, 2013
    #17
  18. glen herrmannsfeldt

    Eric Sosman Guest

    On 6/28/2013 3:39 PM, Giuseppe wrote:
    > [...]
    > Such optimization is enabled by default on Linux. So in order to get
    > a more accurate result, an extra instruction needs to be generated.


    Sometimes optimization improves accuracy, sometimes it makes
    things worse. "Turn on optimization to get better answers" is not
    a reliable stratagem.

    I've fooled around a little bit to concoct an example that may
    give you a better idea of some of the issues. Using paper and
    pencil and ordinary decimal arithmetic, try calculating the sum
    of one-seventh, three-sevenths, and three-sevenths. Clearly, the
    true mathematical value is unity. But decimal arithmetic has the
    same problem with sevenths that binary arithmetic has with fifths:
    You cannot represent their exact values with a finite number of
    digits, so you round the values to some number of places and accept
    the small error introduced by the rounding. The reason I chose
    those three fractions is that the sum can be low, high, or exact
    depending on how many decimal places you use:

    - 0.1 + 0.4 + 0.4 = 0.9, too low
    - 0.14 + 0.43 + 0.43 = 1.00, spot on
    - 0.143 + 0.429 + 0.429 = 1.001, too high
    - 0.1429 + 0.4286 + 0.4286 = 1.0001, too high again
    - 0.14286 + 0.42857 + 0.42857 = 1.00000, exact again
    - 0.142857 + 0.428571 + 0.428571 = 0.999999, too low again

    In these familiar decimal calculations you confront the same problem
    the computer encounters with its less familiar binary arithmetic,
    and you suffer the same kind of inaccuracies. Also, you can see that
    extra precision -- more places -- does not always improve the result.

    There's a large field of study called Numerical Analysis that
    considers the origins, propagation, and management of errors. You
    have now encountered some of the Chapter One material ...

    --
    Eric Sosman
    d
     
    Eric Sosman, Jun 28, 2013
    #18
  19. glen herrmannsfeldt

    Eric Sosman Guest

    On 6/28/2013 4:41 PM, Eric Sosman wrote:
    > [...]
    > - 0.1 + 0.4 + 0.4 = 0.9, too low
    > - 0.14 + 0.43 + 0.43 = 1.00, spot on
    > - 0.143 + 0.429 + 0.429 = 1.001, too high
    > - 0.1429 + 0.4286 + 0.4286 = 1.0001, too high again
    > - 0.14286 + 0.42857 + 0.42857 = 1.00000, exact again
    > - 0.142857 + 0.428571 + 0.428571 = 0.999999, too low again


    On re-reading my example, I see a possible muddle: Those leading
    hyphens are not intended as minus signs, but as list bullets. Sorry
    for any confusion, and for any time folks wasted in subtracting.

    --
    Eric Sosman
    d
     
    Eric Sosman, Jun 28, 2013
    #19
  20. glen herrmannsfeldt

    BartC Guest

    "BartC" <> wrote in message news:_jizt.1921$4...

    > (As it happens, the errors in representing 2.1 and 3.4 seem to cancel each
    > other out in my computer, at least, according to my printf().


    I recall a problem with my printf() where there was a limit to the internal
    precision it will print, no matter what the values given in "%nn.nnf".

    I think the actual values used to represent 2.1 and 3.4 in double precision
    are 2.100000000000000088817841970012523233890533447265625 and
    3.399999999999999911182158029987476766109466552734375. Their sum is still
    exactly 5.5 though!

    Probably for the same sorts of reasons that 1/3 and 2/3, expressed
    approximately as 0.3333 and 0.6667, still add up to 1.0000.

    --
    Bartc
     
    BartC, Jun 28, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. manas

    Text Truncation

    manas, Jul 1, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    533
    Mark Fitzpatrick
    Jul 1, 2005
  2. Marcelo

    MySql Data Truncation

    Marcelo, Dec 19, 2005, in forum: Java
    Replies:
    3
    Views:
    17,214
    Roedy Green
    Dec 21, 2005
  3. Replies:
    3
    Views:
    1,331
    Mike Beaty
    Oct 11, 2006
  4. Replies:
    3
    Views:
    205
    Keith Thompson
    Jun 29, 2013
  5. Keith Thompson

    Re: Unexpected truncation behavior

    Keith Thompson, Jun 28, 2013, in forum: C Programming
    Replies:
    3
    Views:
    224
    Keith Thompson
    Jun 28, 2013
Loading...

Share This Page