Slashdot Mirror

← Back to Stories (view on slashdot.org)

MinGW and MSVCRT Conflict Causes Floating-Point Value Corruption

Posted by timothy on from the internal-conflict dept.

jones_supa writes: If you are working on a C++ program where you need very accurate floating point numbers, you might have decided to use long double data type for the extra precision. After a few calculations, you happen to print your number. To your shock, instead of the number being 123.456789, it is printed out as -6.518427 × 10^264 (or 2.745563 depending on your computer). This is actually a bug in some versions of MinGW g++ 4.8.1 (MinGW is a port of GNU programming tools for Windows). Microsoft's C++ runtime library reserves 80 bits for double and long double. When MinGW uses the Microsoft DLL to print out the value, the number is interpreted as using only 64 bits. This discrepancy causes garbage results to be output.

98 comments

  1. news by itzly · · Score: 0

    Compiler bugs are news ?

    1. Re:news by Anonymous Coward · · Score: 0

      News is what you click on. Particularly what you respond to. DICE gets their pocket money and you get a shitty story about a compiler bug in a point release.

      Hard to accept blame for being partly responsible for ruining the place you apparently adore and love so much, isn't it? Yet here you are.

    2. Re:news by Anonymous Coward · · Score: 0

      I, for one, was absolutely shocked about this bug.

    3. Re:news by itzly · · Score: 1

      News is what you click on

      You don't have to click on it. It just shows up on the front page.

    4. Re:news by Anonymous Coward · · Score: 0

      MingDub sucks.

    5. Re:news by Anonymous Coward · · Score: 0

      You clicked on it, then commented on it, adding to its reach and popularity.

  2. Surprised? by Anne+Thwacks · · Score: -1, Troll

    You used Windows for floating point maths and got the wrong answer? Surely not!

    --
    Sent from my ASR33 using ASCII
    1. Re: Surprised? by SnowDeath · · Score: 1

      And he's runnig this all through bootcamp on a macbook air.

    2. Re: Surprised? by Anonymous Coward · · Score: -1

      Which means it's a 100% windows bug as bootcamp lets windows boot directly to the Intel hardware in the laptop.

      Thanks for the example of how utterly shitty Windows and Intel is.

    3. Re:Surprised? by Anonymous Coward · · Score: 0

      Nope he used MinGW that uses libraries without looking at any documentation, instead it uses them like they worked in its drug fueled pipe dream.

    4. Re:Surprised? by Anonymous Coward · · Score: 0

      You used MinGW? What a fool!

    5. Re: Surprised? by Anonymous Coward · · Score: 1

      FTA

      This is actually a bug in some versions of MinGW g++ 4.8.1.

    6. Re: Surprised? by Anonymous Coward · · Score: 1

      The fine article actually pins it on gcc, and mentions that the later MinGW doesn't have this problem, so the whole /. article isn't very interesting ...

    7. Re:Surprised? by Anonymous Coward · · Score: 0

      You like *read* the summary right? It says in the summary what bit of code is wrong. The open source code BTW if you do not want to read...

      This is a conversion bug. Not a 'windows' bug. It is an easy mistake to make. I have made it myself many times on all the platforms I have used. Bug classification is important. Do not willy nilly blame things. It really makes it hard to fix things. As you may start fixing from the wrong assumption. Then may end up fixing one thing and creating 10 new bugs.

    8. Re:Surprised? by DRJlaw · · Score: 2

      The sage of Wikipedia states

      The actual size and behavior of floating-point types also vary by implementation. The only guarantee is that long double is not smaller than double, which is not smaller than float. Usually, the 32-bit and 64-bit IEEE 754 binary floating-point formats are used, if supported by hardware.

      So the program implementation assumed a behavior that was not guaranteed, and was burned when it used an outside library which was specification compliant but not in the same way as that particular implementation.

      A poor workman blames his tools. And in this case I'm not referring to MinGW, which is admirably neutral in its reporting.

    9. Re:Surprised? by TheRaven64 · · Score: 5, Informative

      It's an ABI mismatch, and the summary is nonsense, saying almost the exact opposite of TFA (which I actually read, because the summary is obvious nonsense). The issue is that the Windows ABI defines long double as being a 64-bit floating point value (which is fine, because the only requirement for long double is that it have no less precision than double. If you're using it and expecting some guaranteed precision for vaguely portable code then you're an idiot). For some reason, MinGW (which aims to be ABI-compatible with MS, at least for C libraries) uses 80-bit x87 values for long double, so you get truncation. I forget the exact calling conventions for Windows i386, but I believe that in some cases this will be silently hidden, as the value will be passed in x87 register and so be transparently extended to 80 bits in the caller and truncated in the callee anyway. It's only if it's passed on the stack (or indirectly via a pointer) that it's a problem.

      It's not obvious which definition of long double is better. On modern x86, you'll use SSE for 32- and 64-bit values, and may lose precision moving between x87 and SSE registers. You also get worse IEEE compliance out of the x87 unit, which may matter more than the extra 16 bits of precision. 80-bit floats are not available on any platform other than x86 (128-bit is more common, though PowerPC has its own special non-IEEE version of these and on some other platforms they're entirely done in software), so they're a bad choice if you want portable code that generates the same output on different platforms.

      --
      I am TheRaven on Soylent News
    10. Re:Surprised? by Anonymous Coward · · Score: 1

      You used GNU's compiler (on Windows) for floating point maths and got the wrong answer? Surely not!

      FTFY.

    11. Re: Surprised? by jones_supa · · Score: 2

      Also earlier versions of MinGW do not have the problem. It's a regression.

    12. Re: Surprised? by jones_supa · · Score: 5, Informative

      Which means it's a 100% windows bug

      No. The MinGW version of GCC allowed to compile programs against the Microsoft C++ runtime library, but the compiler created code which did not follow the spec of the Microsoft library. There really isn't anything to blame about Windows here.

    13. Re:Surprised? by jones_supa · · Score: 1

      saying almost the exact opposite of TFA (which I actually read, because the summary is obvious nonsense).

      Oops, indeed... 80-bit for GCC, 64-bit for MSVCRT. I stand corrected.

    14. Re: Surprised? by Anonymous Coward · · Score: 0

      No, boot camp doesn't. From the older versions of Bootcamp which were essentailly Bios emulation over EFI 1.1 with non-standard extensions, to the new EFI version that actively turns hardware off if you don't boot into OS X, Boot camp doesn not give access to the Intel hardware. In point of fact, one o the things it turns off is the Intel integrated graphics, on dual GPU Macs.

    15. Re:Surprised? by Anonymous Coward · · Score: 0

      the summary is nonsense, saying almost the exact opposite of TFA (which I actually read, because the summary is obvious nonsense).

      Apparently NOT.

      The current bug appears to be a regression bug for this version of g++

      You are correct about the ABI mismatch. But the article clearly puts the blame on MinGW. He even gives links to the patch.

      Again you are not being clear but trying to be. You are being misleading. Doing that causes bugs. I have hundreds of bugs where I chased down a rabbit hole because someone speculated in the bug summary. I have seen hundreds of bugs 'fixed' but were not fixed because someone 'fixed' the wrong thing because of a bad first assumption.

      Basically the G++ compiler was not following the spec. The visual studio compiler was using the IEEE format. Do not mix them if you do not like odd results... It is a very old land mine in compiling things. You sometimes need to know what your compiler does. It is one of those things that you just need to watch for. For example a good land mine (and he briefly touched on it in the article) is printf. printf varies wildly from platform to platform. With different bits implemented in different ways. In some platforms feeding too little or too much data can cause stack overflow/underflow errors. Because you are dealing across platforms they will have assumptions about what it means. You need to be careful when using external APIs they do not always match the OS you are using.

      You will not see this, as much, on other platforms because of their monolithic nature with the compiler. They tend to use one compiler chain. But you can sometimes get oddities like this between compiler releases. I can think of at least 5 different compiler chains you can use on windows. You can also get this oddity when porting code. As that code may have accidentally/intentionally used some side effect of the original compiler. But that may no longer exist on the new platform.

    16. Re:Surprised? by Rockoon · · Score: 0

      You also get worse IEEE compliance out of the x87 unit, which may matter more than the extra 16 bits of precision.

      As far as I am aware, the x87 was fully IEEE compliant so long as you asked for 64-bit (or 32-bit) rounding after every operation (which was implicit if you write all operations back to memory) until Intel decided that precision didnt matter as much as benchmark performance. It was about mid-2014 that Intels newest precision issues made the frontpage of slashdot (Where Intel Processors Fail At Math (Again)

      --
      "His name was James Damore."
    17. Re:Surprised? by Anonymous Coward · · Score: 0

      There is no precision loss when moving from SSE to x87, unless you set a very strange rounding mode. The x87 is IEEE compliant for all but underflow/overflow behavior, if you set the post-operation rounding mode appropiate. There are other platforms supporting the 80bit Intel float format.

    18. Re:Surprised? by ArsenneLupin · · Score: 1

      But the article clearly puts the blame on MinGW.

      Not really...

      He even gives links to the patch.

      ... and this patch makes MinGW use its own implementation of printf (and family...), rather than trusting Microsoft's buggy version.

    19. Re:Surprised? by Mr+Z · · Score: 1

      80-bit floats are not available on any platform other than x86

      The 80-bit long double is also available on the 68881, 68882 coprocessors and later 68K family members that incorporate the FPU. The Itanium also supports the 80-bit format.

      But yeah... those aren't particularly common these days.

      --
      Program Intellivision!
    20. Re:Surprised? by Anonymous Coward · · Score: 0

      here is no precision loss when moving from SSE to x87, unless you set a very strange rounding mode.

      and unless you're using long double on a non-Windows (read: Linux) x64 platform, where sizeof(long double) = 16, i.e. 128 bits.

    21. Re:Surprised? by Anonymous Coward · · Score: 0

      Also, ABI mismatches are common in the MinGW world, so we know to look out for them. Sometimes MinGW even breaks compatibility with itself, like that time when they suddenly without telling anybody changed the standard calling convention of one of its shared (!) DLLs from stdcall to cdecl (if memory serves me correctly). This created a compatibility and support nightmare that cannot really be fixed. I contacted the devs and asked about it, and apparently one of them just sort of ‘flicked the switch’, not for a reason but just because he felt like it, without even thinking of thinking the consequences through. Amateurs.

    22. Re:Surprised? by raxx7 · · Score: 2

      x87 can produce IEEE 754 compliant results if the compiler either sets the correct rounding mode before each operation OR if it stores and reloads the results of each operation into memory (forcing the correct rounding).
      However, both are expensive to do, performance wise, and no compiler does so by default.
      Instead, x87 is normally used a way which is not IEEE 754 compliant, although it's actually a bit more accurate: internally, everything is done with 80 bit precision.
      This results from the fact the x87 unit actually predates the final version of the IEEE 754 standard.

      The IEEE 754 standard only covers a few operations: add, subtract, multiply, divide, FMA,
      The transcendals (sin, cos, tag, exp, pow, etc) functions have never been part of the IEEE 754. Historically, most x87 FPUs have had errors larger than 1 ulp, at least for some part of the range.it
      If I am not mistaken, only the AMD K5 FPU actually provided errors of less than 1 ulp for the entire range of inputs. And please, take this with a large grain of salt.

    23. Re:Surprised? by Anonymous Coward · · Score: 0

      I am perfectly happy with MingW to port my Linux programs.

    24. Re:Surprised? by shutdown+-p+now · · Score: 1

      C standard is not the end-all be-all, there are all specifications that define the details of ABI for a particular architecture and platform. In case of VC++, it is well-documented that long double is the same as double, so any compiler that has an explicit stated goal of being ABI-compatible must respect that.

    25. Re:Surprised? by Anonymous Coward · · Score: 0

      Well, Microsoft's version is not buggy if you use it as Microsoft intended. After all, the VC++ compiler doesn't produce incorrect results. But here's the catch: MSVCRT wasn't designed as a reusable component, so the burden is on MinGW. If reuse of some parts of MSVCRT is too difficult, it's entirely legitimate to rewrite just those.

    26. Re:Surprised? by Anonymous Coward · · Score: 0

      IIRC, the third option for IEEE compliance is to use 80 bits for storage too. Again, expensive. The x87 non-conformance is caused by silently mixing 64 bits and 80 bits FP numbers.

      On an unrelated note, I'm not sure what you mean by "IEEE 754 covering only a few operations, x87 being incorrect". It covers many, many more. However, the core 5 (+-/* and FMA) are required to be exact within 1 ulp. The others have an unspecified error, and at the time it wasn't known which functions could reasonably be specified down to 1 ulp error.

      I think you mean denormalized numbers when you discuss "some part of the range". Those are tricky because 1 ulp isn't well-defined for those numbers. I.e. for 32 bits FP, 1 ulp normally is about 0.001% but the smallest denormal number *is* exacly one ulp (so 100%).

  3. Windows for gnu work? by Anonymous Coward · · Score: 0

    Let me guess, you are running this in boot camp on an intel bad d apple.

  4. Bad title. by olsmeister · · Score: 2

    The title implies that the floating point value becomes corrupt. Without looking into it, it sounds like the value does not become corrupt but rather is just not output correctly. The underlying value is still intact.

    1. Re:Bad title. by Blaskowicz · · Score: 2

      If you wanted to rely on that output, say write to a csv file, the data in the csv file is then effectively corrupt.

    2. Re:Bad title. by Anonymous Coward · · Score: 0

      It's a little more complicated than that.

      Sort version: in g++, "long double" == 80-bit extended precision format, but in MSVCRT "long double" == "double".

      The particular version of g++ bundled with certain builds of MinGW 4.8 apparently does not cast to a double before calling MSVCRT external libraries. In the example given, the only thing the library does is print, so nothing is corrupted. Trying to use the value in calculations would result in garbage, and mutating it from the external library would lead to corruption.

  5. Um by Anonymous Coward · · Score: 0

    ok?

  6. Could be worst by ArcadeMan · · Score: 0, Offtopic

    Try doing the same thing on an original Pentium.

    --
    Get free satoshi (Bitcoin) and Dogecoins
    1. Re:Could be worst by Anonymous Coward · · Score: -1

      Derp. Not only does your comment add nothing to the discussion, but you can't even use "could be worse" correctly.

    2. Re:Could be worst by ArcadeMan · · Score: 0

      Sorry, non-native english.

      --
      Get free satoshi (Bitcoin) and Dogecoins
    3. Re:Could be worst by Anonymous Coward · · Score: 1

      Derp. Not only does your comment add nothing to the discussion, but you can't even use "could be worse" correctly.

      Wow, a self-referencing recursive comment!

    4. Re:Could be worst by Anonymous Coward · · Score: 0

      Doesn't excuse adding nothing to the discussion. Go sit in the corner.

    5. Re:Could be worst by Anonymous Coward · · Score: 0

      Y'all both got it wrong -- it's wurst

  7. the 80 bit issue is well known by 140Mandak262Jamuna · · Score: 4, Insightful
    Intel chips provide 80 bit floating point registers, but the storage is 64 bits. GCC would let you compute all calc in 80 bits all registers are loaded with 64 bit fetch and final result is stored in 64 bits. Intermediate results are 80 bit accurate. Some carefully written expressions can limit their truncation errors.

    This is well known. I had a bug in a tree class due to this. The key stored in the instance was 64 bit, but the compare class evaluated and compared it in 80 bits. One of the most difficult bugs I ever encountered. Highly recursive calls to the compare function failing once in about a billion calls... But that was almost 10 or 12 years ago.

    But one thing. GCC handled the truncations correctly. It allows the 80 bit evaluations turned off by compiler options. I don't mix GCC with msvcrt so I am not sure how old / new this is. My 80 bit adventure was in Linux on Intel chips.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    1. Re:the 80 bit issue is well known by ledow · · Score: 2

      Why the hell were you storing / manipulating a 64-bit key in a tree class as floating-point?

    2. Re:the 80 bit issue is well known by sribe · · Score: 2

      Why the hell were you storing / manipulating a 64-bit key in a tree class as floating-point?

      One would guess that maybe just maybe the natural type of the key was floating point? So then what unnatural type would you suggest he should have used in its place?

      Yes, comparing floating-point numbers is tricky and you have to aware of the issues. No, it is not always wrong to compare them, nor to use them as keys. Would you really argue that it is inappropriate for a database to provide the ability to index a floating-point column???

    3. Re:the 80 bit issue is well known by Anonymous Coward · · Score: 0

      "I don't mix GCC with msvcrt so I am not sure how old / new this is." Why anybody WOULD mix the two and ever expect anything to work, ever, is kind of beyond me. I guess if you have a week to go through everything line-by-line and your project is manageably small enough to do so.

    4. Re: the 80 bit issue is well known by 140Mandak262Jamuna · · Score: 1

      Because it was actually an octree of point clouds keyed on the x y z coordinates?

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    5. Re:the 80 bit issue is well known by gl4ss · · Score: 3, Funny

      "I don't mix GCC with msvcrt so I am not sure how old / new this is." Why anybody WOULD mix the two and ever expect anything to work, ever, is kind of beyond me. I guess if you have a week to go through everything line-by-line and your project is manageably small enough to do so.

      yeah why would you link a windows application against windows ui dll's? maybe to display something using them..

      --
      world was created 5 seconds before this post as it is.
    6. Re:the 80 bit issue is well known by Anonymous Coward · · Score: 0

      GCC would let you compute all calc in 80 bits all registers are loaded with 64 bit fetch and final result is stored in 64 bits

      That's not what GCC does at all. sizeof(long double) == 16. You can fetch and store numbers such as (long double)1 + 1e-18 and they stay intact. In GCC, long double behaves like other floating point types. It just has extra precision. No gotchas.

      This is well known.

      Shorthand for "I'm making stuff up".

    7. Re:the 80 bit issue is well known by rewindustry · · Score: 1

      perhaps because it's a floating point value?

      how else would you compare it?

      ie - what the bleep are you on about?

    8. Re:the 80 bit issue is well known by 140Mandak262Jamuna · · Score: 1

      This is well known.

      Shorthand for "I'm making stuff up".

      The gcc compiler has command line flags to force all floating point expressions to be evaluated strictly using 64bits in register without using the additional 16 bits available. It is that well known.

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    9. Re:the 80 bit issue is well known by jonwil · · Score: 1

      People mix msvcrt and GCC all the time if they are working on Windows. The Windows port of GCC (MingW) uses msvcrt.dll for a large chunk of its C Runtime.

    10. Re:the 80 bit issue is well known by Anonymous Coward · · Score: 0

      That compiler flag is useful to make double arithmetic IEEE-754-compliant. It doesn't affect the long double type which is the topic.

    11. Re:the 80 bit issue is well known by Anonymous Coward · · Score: 0

      Legacy x87 floating point instructions provide 80 bits, modern SSE doesn't.

    12. Re:the 80 bit issue is well known by shutdown+-p+now · · Score: 1

      That has nothing to do with TFA. In gcc, long double is 80-bit when stored so not only it is computed at full x87 precision, that precision is retained. In VC, long double is effectively an alias for double. Both compilers compute with full precision for intermediate values, but that's not the problem here; the problem is that the type with the same name has different representation between them.

    13. Re:the 80 bit issue is well known by StikyPad · · Score: 1

      No, it is not always wrong to compare them, nor to use them as keys.

      That's like saying that it's not always wrong to kill someone. While it's technically true, it's still probably wrong if you're thinking of doing it.

      --
      https://www.eff.org/https-everywhere
  8. Well, from Dice's perspective... by Anonymous Coward · · Score: 5, Informative

    ... this is better than posting stories about SourceForge getting caught highjacking the dev accounts of major OSS projects I guess.

    1. Re:Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      Wtf, did they really do that? I've only read about them including adware/malware in their installers (and I noticed this even before it was news and stopped using SF).

    2. Re:Well, from Dice's perspective... by Anonymous Coward · · Score: 1

      Yes, they did on a Windows version of Gimp. They claimed the account had been abandoned, and they were making it more useful for users.

    3. Re:Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      Yes they did that. They not just added adware to the installers, they also locked out the original devs from the accounts.

      Read this post for more.

    4. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      The account was abadoned. Source Forge does not allow project removal and the GIMP maintainers moved away from it.

      SourceForge also requires OSI compliant licenses which makes this legal.

    5. Re:Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      The maintain SourceForge projects for popular open source software. Recently they took over the GIMP windows project page that hasn't been updated in almost two years.

      They are very explicit about this, the maintainer names are explicitly source forge staff and a large notice shows that this project is not maintained using source forge.

      Hey, this isn't a SourceForge project!

      They offered to return control back to the GIMP maintainers, which was refused. The GIMP maintainers want the project removed from SourceForge.

      Legally SourceForge seems to be in the right, they are not impersonating anyone, they are not keeping anyone from their property and the GPL seems to allow everything they do. The GIMP maintainers in contrast complain about the bundling of adware ( allowed by the GPL ) and the continued redistribution by SourceForge ( allowed by the site terms and a core point of the GPL).

    6. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      Is the adware bundled also GPL?

    7. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 5, Informative

      The account was hijacked. They locked the gimp-win developer out of his account in order to add malware to an open source project. This is big news, but because it's SlashdotMedia doing the shenanigans, it won't appear on the front page. That's pretty stunning that a tech news site censors the most important tech news of the day, but that's what is going on.

    8. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      No. It's a clear violation of the GPL license. Hopefully the EFF will get involved soon.

    9. Re:Well, from Dice's perspective... by epyT-R · · Score: 1

      The issue was the malware wrapper. It abuses the rep of the developers as bait to get people to install the adware.

    10. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      That story was actually on slashdot.

    11. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      No, actually it wasn't.

    12. Re: Well, from Dice's perspective... by caseih · · Score: 1

      No it's not a clear violation of the GPL. Go read the GPL text itself. The GPL refers to the binary itself, not the installer. The binary itself, unmodified (or modified with source code), with a clear link to the source can be distributed easily, wrapped in whatever proprietary installer you want. The GPL is only transmitted through direct linkage. What SF did was certainly unethical, but it wasn't illegal.

    13. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      They aren't distributing the unmodified binary, though. They are distributing they're modification to the code, including the adware, trojans, cryptolocker , and whatever backdoors they choose. That is the violation. If the unmodified binary is what appeared on the consumers machine, then there wouldn't be an issue. That's not the case.

    14. Re:Well, from Dice's perspective... by michelcolman · · Score: 2

      Why don't the GIMP maintainers just accept to take back control, then "update" the project by removing all the source code files and replacing them with funny cat pictures?

    15. Re: Well, from Dice's perspective... by Anonymous Coward · · Score: 0

      The adware is not a modification of GIMP itself, it is only bundled in the SourceForge installer - it forms an aggregate which the GPL explicitly allows. The GIMP binaries when installed should not contain any adware code and the adware binaries should not contain any GIMP code.

  9. Java Compatibility by Anonymous Coward · · Score: -1

    So, it's basically JAVA Compatible, ignoring the IEEE-754 specification.

  10. 64 bits by simula · · Score: 2

    64 bits should be enough for anybody

    1. Re:64 bits by Carewolf · · Score: 2

      64 bits should be enough for anybody

      Yes, and 80bit floating point gives you exactly 64 significant bits ;)

  11. Refreshing by Anonymous Coward · · Score: -1

    It's nice to know that one can rely on Microsoft to do the stupid thing.

    1. Re:Refreshing by Dog-Cow · · Score: 1

      It's nice to know we can rely on the Anonymous Cow-patty to be wrong and insulting at the same time.

      Go kill yourself. You'll feel better.

    2. Re:Refreshing by Anonymous Coward · · Score: 0

      Maybe it wasn't sarcasm or being a jerk, but that he actually meant that Microsoft's own compiler does a proper job here.

    3. Re: Refreshing by Anonymous Coward · · Score: 0

      It's all TheRaven64's fault.

  12. Useful to know... by Anonymous Coward · · Score: 5, Insightful

    But once I've debugged my software and uploaded it to SourceForge can I be sure it won't have an advertising spyware package added to the installer by DICE?

    1. Re:Useful to know... by Anonymous Coward · · Score: 0

      Thank you for your interest in joining the GIMP Windows Adware of DICE* (GIMPWAD)! GIMPWADs worldwide are happy that you'd like to become part of our

      constantly enlarging member ship (come sail away 8======D~)

      Unlike other geek fraternities that you might have heard about, GIMPWAD accepts members of all races, creeds, and colors. We don't even have a technical inclination requirement. As our founders stated in the Annals of GIMPWAD, Chapter 1: "You don't have to be a geek, as long as you like it Greek." They were, of course, referring to the penis in anus style of sexual relations. Don't despair, as attaining full fabulous lifetime status in GIMPWAD is easy. The only prerequisites for membership in Gay Wigger Association of DICE* are that you meet all of the following conditions:

      1. 1. Ownership of penis, anus, or both

      To submit your Gay Wigger Association of DICE* Membership Application, simply do nothing. Congratulations, you're now a GIMPWAD!

      If you require a specific membership number for purposes such as framing, docking, or prestigious inclusion upon your business cards and resume, please take down this number: 69.

      Optionally, you may complete the following survey by replying to this post, indicating affirmative responses with an X in each appropriate box:

      GIMPWAD Membership Survey (OPTIONAL)

      [ ] I am gay
      [ ] I am a wigger
      [ ] I have used SLASHDOT VIDEO to find a sex partner

      After completion of this optional survey, your Slashdot post ID shall serve as your unique Gay Wigger Association of DICE* membership ID.

      Your GIMPWAD membership kit** is on its way.

      * GIMPWAD is neither affiliated with nor endorsed by DICE.COM.

      ** GIMPWAD membership kit no longer includes HIV self-test catheter.

  13. Use 64-bit apps by Anonymous Coward · · Score: 0

    For 64-bit apps, Microsoft defaults to full precision (80-bit long doubles, that is, 64-bit mantissa).
    Check it in float.h (the _PC_53 part, as in Precision Control):

    #if defined (_M_IX86)
          #define _CW_DEFAULT ( _RC_NEAR + _PC_53 + _EM_INVALID + _EM_ZERODIVIDE + _EM_OVERFLOW + _EM_UNDERFLOW + _EM_INEXACT + _EM_DENORMAL)
    #elif defined (_M_X64) || defined (_M_ARM)
          #define _CW_DEFAULT ( _RC_NEAR + _EM_INVALID + _EM_ZERODIVIDE + _EM_OVERFLOW + _EM_UNDERFLOW + _EM_INEXACT + _EM_DENORMAL)
    #endif

  14. Too specific to be worrying by Anonymous Coward · · Score: 0

    I don't see what makes it worth a Slashdot posting reading the blog post, it's actually 1. specific to an old g++ version (4.8), and does not occur in the two more recent versions (4.9 and 5.1); 2. specific to a certain build of g++ on mingw; others are not impacted.

    In short: much ado about very little.

  15. Something seems to be badly garbled in the story by gweihir · · Score: 1

    Gnu C "long double" is 16 bytes long and most decidedly does not fit into 80 bytes.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  16. Re:Something seems to be badly garbled in the stor by gweihir · · Score: 1

    That should be "80 bits"...

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  17. erm.... by Anonymous Coward · · Score: 0

    We are on 4.9.2 even on windoze... just sayin... old news is old news...

    1. Re:erm.... by Cafe+Alpha · · Score: 1

      I don't know about vanilla Mingw, but tdm is on 4.9.2 - just tested, no bug.

  18. Re:Something seems to be badly garbled in the stor by wonkey_monkey · · Score: 2

    It's the other way around. long double is 80 bits long and most decidedly does fit into 16 bytes, which is does so presumably for alignment purposes.

    --
    systemd is Roko's Basilisk.
  19. exactly by rewindustry · · Score: 5, Informative

    SourceForge, the code repository site owned by Slashdot Media, has apparently seized control of the account hosting GIMP for Windows on the service, according to e-mails and discussions amongst members of the GIMP community—locking out GIMP's lead Windows developer. And now anyone downloading the Windows version of the open source image editing tool from SourceForge gets the software wrapped in an installer replete with advertisements.

    http://arstechnica.com/informa...

    The GIMP developers aren't happy at all about this. They say that Sourceforge impersonated the GIMP developers, and abused the trademarks owned by the GNOME foundation.

    https://mail.gnome.org/archive...

    1. Re:exactly by Anonymous Coward · · Score: 0

      Who gives a shit? GIMP sucks anyway. Of all the free graphics packages around, GIMP is the slowest, most cumbersome, and convoluted. Fuck the GIMP developers. Those brain-dead cocksuckers can't even make a decent UI.

    2. Re:exactly by Anonymous Coward · · Score: 0

      Wow great argument fagtron you sure convinced me with those hot opinions.

  20. Mingw is my favorite on windows by Anonymous Coward · · Score: 0

    and this post will not change my mind. Even if I had to use a proprietary but otherwise free compiler on windows, I would definitely go with pellesc and not msvc.

    As far as c++ is concerned, I am idiot and cannot understand it. So I avoid it.

    the question is whether this bug affects dmd or pocc.

  21. its the "long", stupid by Anonymous Coward · · Score: 0

    a datatype of "long double" is truly irrelevant, and an utter representation of stupidity.
    WTF is a "short double"?

    The true problem is a mhoronic presumtion that MSVC is relevant. FALSE.
    A double is 64-bits. A float is is 32-bits. A half-float is 16 bits (only pertinent to ship-dits that believe that 80 bit 'floats' are useful.)

  22. epyT-R why'd you "Run, Forrest: RUN" by Anonymous Coward · · Score: -1

    See subject: From http://slashdot.org/comments.p... ?

    Your "DNS lookup" b.s.?

    1st: Hosts exceed SLOWER remote DNS lookup (Exploit ridden by Kaminsky redirect flaw & 99.999% of ISP DNS != patched vs. it!) - how?

    I avoid DNS putting WHERE I SPEND 95%++ ONLINE TIME @ TOP OF HOSTS via 30 favs!

    2nd: AdBlocking gains speed!

    BOTH exceed remote DNS lag indexed lookup post query/turnaround on resolution (do the math binary search) over 3++ million records w/ a most efficient blocking format = better load + internal parse & no bloat in hosts cached in LOCAL RAM via 2 kernelmode subsystems (diskcache & ip stack = no usermode context switch overhead like Windows' faulty w/ large hosts files usermode dns cache service) vs. remote DNS for utmost in speed, efficiency + reliability (my program keeps hardcodes current) vs. downed DNS too.

    * Hosts = MORE SPEED + EFFICIENCY & ease of maintenance (via http://start64.com/index.php?o...) versus.:

    1.) Remote DNS & hosts do so w/ less resource use + added on app complexity/room for breakdown & exploit w/ added CPU & power use w/ a local setup DNS (worse if separate system) + complexity of deny rules vs. hosts simple entries

    + vs.

    2.) "Almost ALL Ads Blocked": Hosts are far more efficient doing more w/ less vs. AdBlock's BLOAT & regex complexity vs. hosts simple entries. Addons add overheads layered over slower browsers in usermode increasing messagepassing overheads vs. hosts in kernelmode (run some addons concurrently see what I mean). Addons do more added I/O operations + consume more memory & create CPU overuse + complexity (regex vs. hosts entries) bolted-on in SLOW usemode vs. hosts in PURE kernelmode via a high cpu serviced layer of ops by IP stack. Addons = easily detected by native browser methods + clarityray shuts 'em down (hosts aren't).

    APK

    P.S.=> + Hosts != bribed (like AdBlock/ABP NOT DOING THE 1 JOB IT HAD by default)... apk

  23. Re:Something seems to be badly garbled in the stor by shutdown+-p+now · · Score: 1

    It has to do that because arrays of types are required to not have gaps between elements (so that address arithmetic works), and on the other hand they all have to be properly aligned. For modern Intel CPUs, the proper alignment for an 80-bit float is 8 bytes. Hence the smallest value that is equal to or greater than 10 bytes (80 bits) that is divisible by 8 - 16 bytes.

  24. epyT-R why'd you "Run, Forrest: RUN" by Anonymous Coward · · Score: 0

    See subject: From http://slashdot.org/comments.p... ?

    Your "DNS lookup" b.s.?

    1st: Hosts exceed SLOWER remote DNS lookup (Exploit ridden by Kaminsky redirect flaw & 99.999% of ISP DNS != patched vs. it!) - how?

    I avoid DNS putting WHERE I SPEND 95%++ ONLINE TIME @ TOP OF HOSTS via 30 favs!

    2nd: AdBlocking gains speed!

    BOTH exceed remote DNS lag indexed lookup post query/turnaround on resolution (do the math binary search) over 3++ million records w/ a most efficient blocking format = better load + internal parse & no bloat in hosts cached in LOCAL RAM via 2 kernelmode subsystems (diskcache & ip stack = no usermode context switch overhead like Windows' faulty w/ large hosts files usermode dns cache service) vs. remote DNS for utmost in speed, efficiency + reliability (my program keeps hardcodes current) vs. downed DNS too.

    * Hosts = MORE SPEED + EFFICIENCY & ease of maintenance (via http://start64.com/index.php?o...) versus.:

    1.) Remote DNS & hosts do so w/ less resource use + added on app complexity/room for breakdown & exploit w/ added CPU & power use w/ a local setup DNS (worse if separate system) + complexity of deny rules vs. hosts simple entries

    + vs.

    2.) "Almost ALL Ads Blocked": Hosts are far more efficient doing more w/ less vs. AdBlock's BLOAT & regex complexity vs. hosts simple entries. Addons add overheads layered over slower browsers in usermode increasing messagepassing overheads vs. hosts in kernelmode (run some addons concurrently see what I mean). Addons do more added I/O operations + consume more memory & create CPU overuse + complexity (regex vs. hosts entries) bolted-on in SLOW usemode vs. hosts in PURE kernelmode via a high cpu serviced layer of ops by IP stack. Addons = easily detected by native browser methods + clarityray shuts 'em down (hosts aren't).

    APK

    P.S.=> + Hosts != bribed (like AdBlock/ABP NOT DOING THE 1 JOB IT HAD by default)... apk