Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98007 > unrolled thread
| Started by | Potomac <ravine557@gmail.com> |
|---|---|
| First post | 2016-12-05 06:32 -0800 |
| Last post | 2016-12-12 04:18 +0000 |
| Articles | 20 on this page of 107 — 18 participants |
Back to article view | Back to comp.lang.c
Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Potomac <ravine557@gmail.com> - 2016-12-05 06:32 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-05 08:34 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-05 15:43 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-05 10:41 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-05 15:37 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops John Bode <jfbode1029@gmail.com> - 2016-12-05 10:43 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 01:13 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 10:55 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Philip Lantz <prl@canterey.us> - 2016-12-07 20:34 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 11:08 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ian Collins <ian-news@hotmail.com> - 2016-12-08 08:23 +1300
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 01:07 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-07 08:46 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 16:23 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 01:12 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-07 08:49 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops John Bode <jfbode1029@gmail.com> - 2016-12-07 15:07 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 03:46 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 11:59 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 12:05 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-07 09:40 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 15:13 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 20:24 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 16:28 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 21:48 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:02 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 22:19 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:27 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 22:51 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:10 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 14:13 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops David Brown <david.brown@hesbynett.no> - 2016-12-08 15:57 +0100
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ian Collins <ian-news@hotmail.com> - 2016-12-08 18:02 +1300
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-08 08:48 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-07 15:33 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:13 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 14:22 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops David Brown <david.brown@hesbynett.no> - 2016-12-08 16:03 +0100
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 10:44 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Melzzzzz <Melzzzzz@zzzzz.com> - 2016-12-08 15:48 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:41 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 16:16 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:47 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-08 20:16 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops David Brown <david.brown@hesbynett.no> - 2016-12-09 11:19 +0100
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-09 08:00 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-13 13:10 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-13 13:55 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 01:13 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-15 07:02 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 19:56 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-18 10:00 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-14 11:45 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-14 12:14 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 01:24 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-15 08:02 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-15 12:10 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Philip Lantz <prl@canterey.us> - 2016-12-16 20:00 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 11:05 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:21 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-09 13:10 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:44 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-10 10:18 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:18 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:26 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 11:15 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:31 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:47 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:05 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:21 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:15 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 18:57 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:05 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:09 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:25 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:59 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-08 13:51 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-08 13:34 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:52 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-08 19:33 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 11:20 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-09 13:28 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:51 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:46 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 13:55 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 20:17 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-07 12:23 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops twalker470@googlemail.com - 2016-12-07 05:50 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-07 08:55 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 16:23 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-07 10:56 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 04:14 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Barry Schwarz <schwarzb@dqel.com> - 2016-12-07 11:03 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops John Bode <jfbode1029@gmail.com> - 2016-12-09 08:06 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-09 09:23 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 17:38 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 14:01 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 19:09 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-09 12:38 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:08 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:16 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:59 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 11:51 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:22 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:52 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:32 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:18 +0000
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 11:20 -0500 |
| Message-ID | <o2elhq$1ga$1@jstuckle.eternal-september.org> |
| In reply to | #98449 |
On 12/8/2016 10:33 PM, jameskuyper@verizon.net wrote: > On Thursday, December 8, 2016 at 9:52:59 PM UTC-5, Jerry Stuckle wrote: >> On 12/8/2016 4:34 PM, jameskuyper@verizon.net wrote: >>> On Thursday, December 8, 2016 at 9:13:10 AM UTC-5, Jerry Stuckle wrote: >>>> On 12/7/2016 6:33 PM, jameskuyper@verizon.net wrote: >>>>> On Wednesday, December 7, 2016 at 3:13:27 PM UTC-5, Jerry Stuckle wrote: >>>>>> On 12/7/2016 12:40 PM, Keith Thompson wrote: >>>>> ... >>>>>>> Most C compilers are not conforming by default, and require some added >>>>>>> options to make them (atte > ... >>>>>> Why do you say that? There is nothing that says a compiler can't add >>>>>> features, as long as it does everything the standard says it does. > ... >>>> When they support multiple versions of the standard, they need to know >>>> which version of the standard to use. ... >>> >>> True, but not directly to the point. C compilers, by (debateable, and >>> frequently debated) definition, have at least mode where they fully conform to >>> some version of the standard. They may have other modes in which they fully >>> conform to other versions of the standard. However, it's an odd fact, but true, >>> that most compilers also support one or more mode that don't fully conform to >>> any version of the standard (though they do come close), and for most >>> compilers, the default mode, the mode that is used when no options are >>> selected, is one of those non-conforming modes. >>> >> >> Yes, directly to the point. And there is nothing in the C standard that >> says the compiler must be compliant in its default mode. ... > > Richard was the one who suggested that C compilers should, by default, be in > conforming mode. However, he was not claiming that this was a requirement of > the standard - he was merely expressing a preference. > Keith responded by pointing out that, in conflict with Richard's preferences, > most compilers are non-conforming in their default mode. He did not, in any > way, imply that they had any obligation to conform in their default mode. > > You claimed he was wrong about that, and that claim has been the reason for my > follow-up messages. At least six of the most popular compilers have already > been mentioned in this thread as being non-conforming in their default mode: > gcc > Borland > Visual Studio > Code Warrior > C/370 > LE370 > > Sun's compilers were proposed as an example of a compiler that conformed by > default, but Keith demonstrated that Sun Studio 12 does not fully conform, > either. > > I can add the MIPS-PRO C compiler that my project used on SGI machines. At a > minimum, you had to supply the -ansi and -lm options to make it a fully > conforming implementation of C. > > including the compiler used by the OP. > > You have yet to name one, though at one point you expressed the opinion that > most do. If you were right about that, it should have been possible to identify > at least one. > Which I already admitted that was wrong. But you can't let it go, can you? You're as bad as Richard. >> ... And I didn't >> say that compilers couldn't be non-compliant - just that every compiler >> out there I know of is compliant. > > Then could you identify them, because most of the most popular compilers known > to people monitoring this group have turned out to be non-conforming in their > default mode. Only eight such compilers have been discussed in this thread, but > many more have been discussed in previous threads talking about this same issue. > I didn't say they were necessarily compliant in default mode - I have already corrected that statement multiple times. But you can't let it go, can you? You're as bad as Richard. >>>> ... But -lm is a linker parameter, >>>> not compiler. >>> >>> Most of the compilers that I've used in the past several decades have accepted >>> -lm as an option, will invoke the linker automatically, and pass that option to >>> the linker. > ... >> The compiler doesn't do anything with the -l flag option except pass it > > Nontheless, it does accept the option, and does do something with it (passing > it on). I believe that's also true of many of gcc's other options. I don't > know all the details, but I gather that gcc does very little work itself; most > of the work is done by other programs opened up as sub-processes under the gcc > process. Most of the options that gcc takes are simply passed on to one of > those other programs, rather than being implmented by gcc itself. The linker > just happens to be one of the several other programs it does this with. > Actually, it is not the compiler that accepts the option. gcc is a front end, passing the appropriate flags to the compiler and linker. So no, the compiler does not "accept the option". It doesn't even see the option. >> on to the linker. And the linker is common to all compiled languages - > > Not necessarily. C++, in particular, imposes requirements on how C++ programs > are linked together that are incompatible with the common linker on many > platforms. As a result, in many cases C++ is implemented by providing it's own > specialize linker to implement those features. I suspect that C++ is far from > being the only language that does such things; but I'm not as familiar with > those other languages. > We're not talking C++. >> not just C. The C standard does not specify linker operations. > > Correct, just like it doesn't specify compiler operations. What it does specify > is the required steps of translation, and the linker performs the steps that > the standard requires to be performed during translation phase 8. Something > does not qualify as a fully conforming implementation of C unless it actually > implements phase 8; compilers by themselves never qualify - a compiler that > automatically calls the linker for you could qualify, but if it requires the > -lm option to correctly translate programs that use <math.h>, then it is not > fully conforming in the default mode, where no options are provided. > And the only requirement is that external references be satisfied. It does not say they must be satisfied by a linker. They could, for instance, be satisfied by the OS at program load time. Perfectly within the requirements of the standard. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-09 13:28 -0800 |
| Message-ID | <7e7fa31d-29aa-44c4-9164-e110f20c27a8@googlegroups.com> |
| In reply to | #98551 |
On Friday, December 9, 2016 at 11:20:35 AM UTC-5, Jerry Stuckle wrote: > On 12/8/2016 10:33 PM, jameskuyper@verizon.net wrote: > > On Thursday, December 8, 2016 at 9:52:59 PM UTC-5, Jerry Stuckle wrote: ... > > Keith responded by pointing out that, in conflict with Richard's preferences, > > most compilers are non-conforming in their default mode. He did not, in any > > way, imply that they had any obligation to conform in their default mode. > > > > You claimed he was wrong about that, and that claim has been the reason for > > my follow-up messages. ... > > You have yet to name one, though at one point you expressed the opinion that > > most do. If you were right about that, it should have been possible to > > identify at least one. > > > > Which I already admitted that was wrong. I haven't seen that admission, and judging from Richard, he can't find it either. However, like Richard, I'm willing to accept that admission now. ... > >> ... And I didn't > >> say that compilers couldn't be non-compliant - just that every compiler > >> out there I know of is compliant. > > > > Then could you identify them, because most of the most popular compilers > > known to people monitoring this group have turned out to be non-conforming > > in their default mode. Only eight such compilers have been discussed in > > this thread, but many more have been discussed in previous threads talking > > about this same issue. > > I didn't say they were necessarily compliant in default mode And I never claimed that you said that. Rather, what you have frequently done is OBJECT to the claim that they were necessarily conforming in their default mode. As far as I know, you have never retracted that objection, and it's that objection that I'm objecting to. It only makes sense to object to that claim, if someone had actually made it - but no one has made that claim. You, on the other hand, have frequently objected to it - which would be quite odd unless you thought, incorrectly, that someone was making that argument. ... > >> on to the linker. And the linker is common to all compiled languages - > > > > Not necessarily. C++, in particular, imposes requirements on how C++ > > programs are linked together that are incompatible with the common linker > > on many platforms. As a result, in many cases C++ is implemented by > > providing it's own specialize linker to implement those features. I suspect > > that C++ is far from being the only language that does such things; but I'm > > not as familiar with those other languages. > > We're not talking C++. We aren't? You made a statement about "all compiled languages", for which C++ is a valid counter-example. Are you saying that C++ isn't a compiled language, so your statement about "all compiled languages" doesn't apply to it? > >> not just C. The C standard does not specify linker operations. > > > > Correct, just like it doesn't specify compiler operations. What it does > > specify is the required steps of translation, and the linker performs the > > steps that the standard requires to be performed during translation phase > > 8. Something does not qualify as a fully conforming implementation of C > > unless it actually implements phase 8; compilers by themselves never > > qualify - a compiler that automatically calls the linker for you could > > qualify ... > And the only requirement is that external references be satisfied. It > does not say they must be satisfied by a linker. So we're in agreement on that point? Good.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 23:51 -0500 |
| Message-ID | <o2g1hl$hde$1@jstuckle.eternal-september.org> |
| In reply to | #98611 |
On 12/9/2016 4:28 PM, jameskuyper@verizon.net wrote: > On Friday, December 9, 2016 at 11:20:35 AM UTC-5, Jerry Stuckle wrote: >> On 12/8/2016 10:33 PM, jameskuyper@verizon.net wrote: >>> On Thursday, December 8, 2016 at 9:52:59 PM UTC-5, Jerry Stuckle wrote: > ... >>> Keith responded by pointing out that, in conflict with Richard's preferences, >>> most compilers are non-conforming in their default mode. He did not, in any >>> way, imply that they had any obligation to conform in their default mode. >>> >>> You claimed he was wrong about that, and that claim has been the reason for >>> my follow-up messages. > ... >>> You have yet to name one, though at one point you expressed the opinion that >>> most do. If you were right about that, it should have been possible to >>> identify at least one. >>> >> >> Which I already admitted that was wrong. > > I haven't seen that admission, and judging from Richard, he can't find it > either. However, like Richard, I'm willing to accept that admission now. > Then you have a reading comprehension problem. I agreed to that two or three days ago, but you continue on. > ... >>>> ... And I didn't >>>> say that compilers couldn't be non-compliant - just that every compiler >>>> out there I know of is compliant. >>> >>> Then could you identify them, because most of the most popular compilers >>> known to people monitoring this group have turned out to be non-conforming >>> in their default mode. Only eight such compilers have been discussed in >>> this thread, but many more have been discussed in previous threads talking >>> about this same issue. >> >> I didn't say they were necessarily compliant in default mode > > And I never claimed that you said that. > Then why are you arguing? > Rather, what you have frequently done is OBJECT to the claim that they were > necessarily conforming in their default mode. As far as I know, you have never > retracted that objection, and it's that objection that I'm objecting to. It > only makes sense to object to that claim, if someone had actually made it - but > no one has made that claim. You, on the other hand, have frequently objected to > it - which would be quite odd unless you thought, incorrectly, that someone was > making that argument. > I have not "frequently" objected to the claim, and I have already agreed multiple times that statement was incorrect. But you can't let it go, can you? Either you have reading comprehension problems, or you're arguing just to argue. > ... >>>> on to the linker. And the linker is common to all compiled languages - >>> >>> Not necessarily. C++, in particular, imposes requirements on how C++ >>> programs are linked together that are incompatible with the common linker >>> on many platforms. As a result, in many cases C++ is implemented by >>> providing it's own specialize linker to implement those features. I suspect >>> that C++ is far from being the only language that does such things; but I'm >>> not as familiar with those other languages. >> >> We're not talking C++. > > We aren't? You made a statement about "all compiled languages", for which C++ > is a valid counter-example. Are you saying that C++ isn't a compiled language, > so your statement about "all compiled languages" doesn't apply to it? > Yes, the linker is common to all compiled languages - including C++. I never said that C++ didn't impose any requirements on the linker - only that C didn't. But your reading comprehension is showing again. Or once again you are arguing just to argue. Which is it? >>>> not just C. The C standard does not specify linker operations. >>> >>> Correct, just like it doesn't specify compiler operations. What it does >>> specify is the required steps of translation, and the linker performs the >>> steps that the standard requires to be performed during translation phase >>> 8. Something does not qualify as a fully conforming implementation of C >>> unless it actually implements phase 8; compilers by themselves never >>> qualify - a compiler that automatically calls the linker for you could >>> qualify ... >> And the only requirement is that external references be satisfied. It >> does not say they must be satisfied by a linker. > > So we're in agreement on that point? Good. > I never said anything different. So why are you arguing? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 16:46 +0000 |
| Message-ID | <o2en2c$81g$1@dont-email.me> |
| In reply to | #98449 |
On 09/12/16 03:33, jameskuyper@verizon.net wrote: > On Thursday, December 8, 2016 at 9:52:59 PM UTC-5, Jerry Stuckle wrote: <snip> >> >> Yes, directly to the point. And there is nothing in the C standard that >> says the compiler must be compliant in its default mode. ... > > Richard was the one who suggested that C compilers should, by default, be in > conforming mode. No, I didn't suggest that, or at least I certainly don't recall doing so. All I said was that if the OP had acquired Visual Studio having been led by its vendor to believe it to be a conforming C compiler, and if that compiler refused to translate a correct program that called scanf, then he had every right to a refund. Unpacking that just a little: the OP didn't pay for the product, so there won't be a refund under any circumstances! More importantly, Visual Studio almost certainly /can/ be kicked into conforming mode in order to allow the use of scanf. It is most certainly *not* my contention that Visual Studio doesn't have a conforming mode. At no point did I suggest that Visual Studio was required, or even /should/ be required, to conform out of the box. As long as there is a documented way to make it conform, it conforms, and that's fine. > However, he was not claiming that this was a requirement of > the standard - he was merely expressing a preference. Not even that. > Keith responded by pointing out that, in conflict with Richard's preferences, No, sir. > most compilers are non-conforming in their default mode. He did not, in any > way, imply that they had any obligation to conform in their default mode. Correct. > You claimed he was wrong about that, and that claim has been the reason for my > follow-up messages. Likewise. He now says he has admitted he was wrong, and batted on for ages about how we're now not letting it go. But although I recall his accepting that gcc is not conforming in default mode, I don't recall the original admission that his general claim (i.e. that most C compilers conform in default mode) was wrong, and I can find no evidence to support his claim that he has made this more general admission. Having said that, he does now say he was wrong. We have succeeded, then, where Jerry failed - we have taught the pig to sing! Only one note, and not very tuneful, but it's definitely a start. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-09 13:55 -0500 |
| Message-ID | <2f1faf3c-26ce-fc42-ebff-df9a1a6acf9d@verizon.net> |
| In reply to | #98563 |
On 12/09/2016 11:46 AM, Richard Heathfield wrote: > On 09/12/16 03:33, jameskuyper@verizon.net wrote: ... >> Richard was the one who suggested that C compilers should, by default, be in >> conforming mode. > > No, I didn't suggest that, or at least I certainly don't recall doing > so. All I said was that if the OP had acquired Visual Studio having been > led by its vendor to believe it to be a conforming C compiler, and if > that compiler refused to translate a correct program that called scanf, > then he had every right to a refund. > > Unpacking that just a little: the OP didn't pay for the product, so > there won't be a refund under any circumstances! More importantly, > Visual Studio almost certainly /can/ be kicked into conforming mode in > order to allow the use of scanf. It is most certainly *not* my > contention that Visual Studio doesn't have a conforming mode. > > At no point did I suggest that Visual Studio was required, or even > /should/ be required, to conform out of the box. As long as there is a > documented way to make it conform, it conforms, and that's fine. Sorry - I misread your statement. Now that I've had a partial night's sleep (Allen woke us up with screaming at 04:00, when I still needed three more hour's sleep), your meaning is clearer than it was last night.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-07 20:17 +0000 |
| Message-ID | <o29qmq$d50$2@dont-email.me> |
| In reply to | #98276 |
On 07/12/16 17:40, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > [...] >>> Someone told me to put this line before the statements, but it >>> doesn't make the error message go away. What would you suggest? You snipped too many attributions. The above was written by potomac, not me. The chevrons are right, but even so... -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-07 12:23 -0800 |
| Message-ID | <lnvauv1oas.fsf@kst-u.example.com> |
| In reply to | #98290 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 07/12/16 17:40, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [...]
>>>> Someone told me to put this line before the statements, but it
>>>> doesn't make the error message go away. What would you suggest?
>
> You snipped too many attributions. The above was written by potomac, not
> me. The chevrons are right, but even so...
Sorry about that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | twalker470@googlemail.com |
|---|---|
| Date | 2016-12-07 05:50 -0800 |
| Message-ID | <886bb8f0-6ed2-4a62-8bd2-e7146dedcc93@googlegroups.com> |
| In reply to | #98246 |
On Wednesday, 7 December 2016 11:46:29 UTC, potomac wrote:
> Whoops, I meant to type: float value[5] = { 100, 100, 100, 100, 100 };
>
> Even though that definitely gives the same output, there must be some good reason the author chose the other method of initializing. Is it because the macro affords flexibility?
>
>
> Ben, as for scanf_s, I keep using that it my code because I haven't yet figured out a way to make the error message go away in Visual Studio 2015 and won't let me run the program. I understand that scan_s is for security against buffer attacks and that it's proprietary to Visual Studio
>
> Someone told me to put this line before the statements, but it doesn't make the error message go away. What would you suggest?
>
> #define _CRT_SECURE_NO_DEPRECATE
#define _CRT_SECURE_NO_WARNINGS seems to do the trick.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-12-07 08:55 -0700 |
| Message-ID | <1b1sxjpwcu.fsf@pfeifferfamily.net> |
| In reply to | #98246 |
potomac <ravine557@gmail.com> writes:
> Whoops, I meant to type: float value[5] = { 100, 100, 100, 100, 100 };
>
> Even though that definitely gives the same output, there must be some
> good reason the author chose the other method of initializing. Is it
> because the macro affords flexibility?
Ah! That explains it! I was a little confused before. It's less
because of flexibility than because of the prospect of errors if you
miscount, and of course in a larger program you might well be
initializing thousands or millions of values and the loop will save you
a *lot* of typing.
Notice that you could also have avoided the loop with
float value[5] = {INITIAL_BALANCE INITIAL_BALANCE INITIAL_BALANCE
INITIAL_BALANCE INITIAL_BALANCE };
so if you wanted to change the initial balance you could do it in just
one place.
A general rule I use in my code is that any time I have to type
something twice I'm doing something wrong. Maybe I need a macro, maybe
a function, maybe a loop. But every time I retype it I've introduced
the opportunity for a bug either now or while the program is being
maintained.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-07 16:23 +0000 |
| Message-ID | <o29d0a$pls$2@dont-email.me> |
| In reply to | #98269 |
On 07/12/16 15:55, Joe Pfeiffer wrote:
<snip>
>
> float value[5] = {INITIAL_BALANCE INITIAL_BALANCE INITIAL_BALANCE
> INITIAL_BALANCE INITIAL_BALANCE };
ITYM float value[5] = {INITIAL_BALANCE, INITIAL_BALANCE,
INITIAL_BALANCE, INITIAL_BALANCE, INITIAL_BALANCE };
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-12-07 10:56 -0700 |
| Message-ID | <1bwpfboc6b.fsf@pfeifferfamily.net> |
| In reply to | #98272 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 07/12/16 15:55, Joe Pfeiffer wrote:
> <snip>
>>
>> float value[5] = {INITIAL_BALANCE INITIAL_BALANCE INITIAL_BALANCE
>> INITIAL_BALANCE INITIAL_BALANCE };
>
> ITYM float value[5] = {INITIAL_BALANCE, INITIAL_BALANCE,
> INITIAL_BALANCE, INITIAL_BALANCE, INITIAL_BALANCE };
You are, of course, correct.
[toc] | [prev] | [next] | [standalone]
| From | potomac <ravine557@gmail.com> |
|---|---|
| Date | 2016-12-07 04:14 -0800 |
| Message-ID | <5d157f88-20fc-47bb-ada0-78a813766df6@googlegroups.com> |
| In reply to | #98007 |
Ha! Getting my money back. I have the free "Community" version that was released this year. It's identical to the pro version, minus the telephone support
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-07 11:03 -0800 |
| Message-ID | <40ng4ctsu27t6htcldtik3asd68kahoqm7@4ax.com> |
| In reply to | #98251 |
On Wed, 7 Dec 2016 04:14:58 -0800 (PST), potomac <ravine557@gmail.com> wrote: >Ha! Getting my money back. > >I have the free "Community" version that was released this year. It's identical to the pro version, minus the telephone support Be aware that a compiler is allowed to issue any diagnostic it wants as long as it accepts a conforming program. As others have noted, most compilers are not conforming in default mode. There is an option in VS to change the 4996 diagnostic from an error to a warning that will not prevent your program from compiling. But you already have two options (one corrected, one new) to suppress the diagnostic completely so that should no longer be an issue. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-12-09 08:06 -0800 |
| Message-ID | <a6691add-3701-4a38-b760-d7a05f7317bb@googlegroups.com> |
| In reply to | #98007 |
On Monday, December 5, 2016 at 8:32:38 AM UTC-6, potomac wrote: [snippity] > float value[5]; Apropos of nothing else in this thread, note that a lot of (if not most) real-world financial software does *NOT* use floating point to store currency amounts. It's far more common to use an integral type or an integral sequence (such as BCD) to store currency values, scaled to the smallest unit (cents or mils). For example, the integral value 12345 can represent $123.45 in cents, or $12.345 in mils. Floating-point introduces a bit too much imprecision, especially since you cannot represent a value like 0.1 or 0.01 *exactly* in most floating-point formats. We may use floating point for some calculations, but the result will be stored back to an integral type (with appropriate rounding rules).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-09 09:23 -0800 |
| Message-ID | <ln60mtyq1c.fsf@kst-u.example.com> |
| In reply to | #98546 |
John Bode <jfbode1029@gmail.com> writes:
> On Monday, December 5, 2016 at 8:32:38 AM UTC-6, potomac wrote:
>
> [snippity]
>
>> float value[5];
>
> Apropos of nothing else in this thread, note that a lot of (if not most)
> real-world financial software does *NOT* use floating point to store
> currency amounts. It's far more common to use an integral type or an
> integral sequence (such as BCD) to store currency values, scaled to the
> smallest unit (cents or mils).
>
> For example, the integral value 12345 can represent $123.45 in cents, or
> $12.345 in mils. Floating-point introduces a bit too much imprecision,
> especially since you cannot represent a value like 0.1 or 0.01 *exactly*
> in most floating-point formats.
>
> We may use floating point for some calculations, but the result will be
> stored back to an integral type (with appropriate rounding rules).
Agreed (I think).
However, storing money values in integers representing the smallest
unit (cents, mils, whatever), though it's almost certainly better
than floating-point, doesn't entirely solve the problem. There are
financial calculations that yield results that are not whole numbers
of cents or mils. For example, you might need to start with some
amount of money and then apply one day's interest at 5% per annum,
compounded daily. Multiplying a whole number by 1.05**(1/365)
(or is it 360?) will not yield a whole number.
There are, as I understand it, consistent rules, set by law, for
how these calculations are to be performed. Doing the computation
in a manner that yields a different result than the one required
by the rules can get you in big trouble.
I have no idea what those rules actually are, but if I were working
on financial software I presumably would have to. (It's not
inconceivable that the rules are written in terms of floating-point
calculations.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 17:38 +0000 |
| Message-ID | <o2eq4g$kmb$1@dont-email.me> |
| In reply to | #98574 |
On 09/12/16 17:23, Keith Thompson wrote:
<snip>
> However, storing money values in integers representing the smallest
> unit (cents, mils, whatever), though it's almost certainly better
> than floating-point, doesn't entirely solve the problem. There are
> financial calculations that yield results that are not whole numbers
> of cents or mils. For example, you might need to start with some
> amount of money and then apply one day's interest at 5% per annum,
> compounded daily. Multiplying a whole number by 1.05**(1/365)
> (or is it 360?) will not yield a whole number.
This is why banks typically calculate interest daily but add it yearly
(or twice-yearly or quarterly).
They will have something like this:
foo
{
long int balance; /* or long long int in C99+ */
double interest;
}
and each day they'll do this:
myfoo.interest += (myfoo.balance + myfoo.interest) *
(1.0 + getdayrate());
(Jacob will have a fit if I don't point out that I'm simplifying, and
that precautions are taken against overflow.)
and then at year end they'll do this:
myfoo.balance += myfoo.interest;
myfoo.interest = 0.0;
> There are, as I understand it, consistent rules, set by law, for
> how these calculations are to be performed. Doing the computation
> in a manner that yields a different result than the one required
> by the rules can get you in big trouble.
Yes, that's correct. Well, probably quite small trouble if you didn't do
it on purpose and if the difference is minor. But still trouble, yes.
> I have no idea what those rules actually are, but if I were working
> on financial software I presumably would have to. (It's not
> inconceivable that the rules are written in terms of floating-point
> calculations.)
In the world of insurance (or at least the UK part of it), for example,
roll-up calculations have to be correct to six decimal places at the end
of the roll-up. (So an endowment policy, say, must be correct to within
one ten thousandth of a penny at the end of even a 35-year investment.)
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-09 14:01 -0500 |
| Message-ID | <c82d0059-5d77-6549-0499-f875c8ecc145@verizon.net> |
| In reply to | #98578 |
On 12/09/2016 12:38 PM, Richard Heathfield wrote:
...
> This is why banks typically calculate interest daily but add it yearly
> (or twice-yearly or quarterly).
>
> They will have something like this:
>
> foo
> {
> long int balance; /* or long long int in C99+ */
> double interest;
> }
>
> and each day they'll do this:
>
> myfoo.interest += (myfoo.balance + myfoo.interest) *
> (1.0 + getdayrate());
>
> (Jacob will have a fit if I don't point out that I'm simplifying, and
> that precautions are taken against overflow.)
>
> and then at year end they'll do this:
>
> myfoo.balance += myfoo.interest;
> myfoo.interest = 0.0;
I'd be inclined to write that a little differently:
integer_part = myfoo.interest;
myfoo.interest -= integer_part;
myfoo.balance += integer_part;
In other words, the unused fractional part of the accumulated interest
carries over to the next time period. I've no idea whether such an idea
would be consistent with the government's rules about such things.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 19:09 +0000 |
| Message-ID | <o2evf7$b53$1@dont-email.me> |
| In reply to | #98597 |
On 09/12/16 19:01, James R. Kuyper wrote: > On 12/09/2016 12:38 PM, Richard Heathfield wrote: > ... <snip> >> and then at year end they'll do this: >> >> myfoo.balance += myfoo.interest; >> myfoo.interest = 0.0; > > I'd be inclined to write that a little differently: > > integer_part = myfoo.interest; > myfoo.interest -= integer_part; > myfoo.balance += integer_part; Whether that is in the bank's interest depends on whether it's a deposit account or a loan account. :-) > In other words, the unused fractional part of the accumulated interest > carries over to the next time period. I've no idea whether such an idea > would be consistent with the government's rules about such things. It would certainly be a fairer way to do things. Although I've worked at a couple of banks, I've never been involved in year end stuff, so I haven't seen how they actually do this, but the above represents the basic idea (quite possibly including your mod). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-12-09 12:38 -0700 |
| Message-ID | <1bshpwoptj.fsf@pfeifferfamily.net> |
| In reply to | #98599 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 09/12/16 19:01, James R. Kuyper wrote:
>>
>> integer_part = myfoo.interest;
>> myfoo.interest -= integer_part;
>> myfoo.balance += integer_part;
>
> Whether that is in the bank's interest depends on whether it's a
^^^^^^^^ :)
> deposit account or a loan account. :-)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-10 00:08 -0500 |
| Message-ID | <o2g2i5$jnr$1@jstuckle.eternal-september.org> |
| In reply to | #98578 |
On 12/9/2016 12:38 PM, Richard Heathfield wrote:
> On 09/12/16 17:23, Keith Thompson wrote:
>
> <snip>
>
>> However, storing money values in integers representing the smallest
>> unit (cents, mils, whatever), though it's almost certainly better
>> than floating-point, doesn't entirely solve the problem. There are
>> financial calculations that yield results that are not whole numbers
>> of cents or mils. For example, you might need to start with some
>> amount of money and then apply one day's interest at 5% per annum,
>> compounded daily. Multiplying a whole number by 1.05**(1/365)
>> (or is it 360?) will not yield a whole number.
>
> This is why banks typically calculate interest daily but add it yearly
> (or twice-yearly or quarterly).
>
> They will have something like this:
>
> foo
> {
> long int balance; /* or long long int in C99+ */
> double interest;
> }
>
> and each day they'll do this:
>
> myfoo.interest += (myfoo.balance + myfoo.interest) *
> (1.0 + getdayrate());
>
> (Jacob will have a fit if I don't point out that I'm simplifying, and
> that precautions are taken against overflow.)
>
> and then at year end they'll do this:
>
> myfoo.balance += myfoo.interest;
> myfoo.interest = 0.0;
>
Actually, it's a bit more insidious than that. By calculating it daily,
they add to their assets. When they add it to their customers'
accounts, it becomes a payable item. Doing it this way allows them to
"float" the money and use it for other things (like investments).
A bit shady, but a perfectly legal loophole.
>> There are, as I understand it, consistent rules, set by law, for
>> how these calculations are to be performed. Doing the computation
>> in a manner that yields a different result than the one required
>> by the rules can get you in big trouble.
>
> Yes, that's correct. Well, probably quite small trouble if you didn't do
> it on purpose and if the difference is minor. But still trouble, yes.
>
No, he's right. At least in the U.S., whether it is intentional or not
is immaterial (and probably virtually impossible to prove). But even a
small amount could get the financial institution into big trouble. The
Feds take a very dim view of it.
>> I have no idea what those rules actually are, but if I were working
>> on financial software I presumably would have to. (It's not
>> inconceivable that the rules are written in terms of floating-point
>> calculations.)
>
> In the world of insurance (or at least the UK part of it), for example,
> roll-up calculations have to be correct to six decimal places at the end
> of the roll-up. (So an endowment policy, say, must be correct to within
> one ten thousandth of a penny at the end of even a 35-year investment.)
>
Same here in the U.S. It may seem like a small amount, but when dealing
with compound interest for millions of customers, it can quickly become
a rather large amount.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web