From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,388fc53f584bd695 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.glorb.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Vinzent Hoefler" Newsgroups: comp.lang.ada Subject: Re: Fixed point constants issue Date: Tue, 14 Sep 2010 19:42:52 +0200 Message-ID: References: <1f0l0baynq1x7$.phl9cqpwcr37.dlg@40tude.net> <1ak1k4eh1p96t$.essf9fu1cx4z$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: individual.net TgZlqRv9YW0eGvlkTJW3wwy/h03QxzDUy06azvBpMwj5p9x4Kh Cancel-Lock: sha1:P3CGREsxdPxRtEE1m7/QEQphKLg= User-Agent: Opera Mail/10.62 (Win32) Xref: g2news1.google.com comp.lang.ada:14078 Date: 2010-09-14T19:42:52+02:00 List-Id: On Tue, 14 Sep 2010 09:47:03 +0200, Dmitry A. Kazakov wrote: > Well, I don't disagree, but the part of the problem is a non-intended > use. Well, the actually intended use was to create a range constrained subtype from an existing full-range fixed point type: -- 8< -- snip -- type BASE_TYPE is delta 1.0 / 64.0 range 0.0 .. 1.0; for BASE_TYPE'Small use 1.0 / 128.0; UPPER_BOUND_1 : constant := 51.0 * 0.01; UPPER_BOUND_2 : constant BASE_TYPE := 51.0 * 0.01; UPPER_BOUND_3 : constant BASE_TYPE := BASE_TYPE (51.0 * 0.01); subtype SUB1_TYPE is BASE_TYPE range 0.0 .. UPPER_BOUND_1; subtype SUB2_TYPE is BASE_TYPE range 0.0 .. UPPER_BOUND_2; subtype SUB3_TYPE is BASE_TYPE range 0.0 .. UPPER_BOUND_3; -- 8< -- snip -- (Further details of the test procedure omitted to save space.) The numbers are arbitrarily chosen and in the real code we weren't using constants, but rather the raw expression like in "range 0.0 .. SOME_CONSTANT * SOME_OTHER_CONSTANT" (but that doesn't actually matter, the issue remains the same, if not to say totally consistent). Now, interestingly, the resulting ranges of the subtypes seem to be compiler-dependent: -- 8< -- snip -- ~/project/fixed_point_issue> build fixed_point.bld Registering Ada Sources Compiling /home/hoefler/project/fixed_point_issue/fixed_point.adb because "fixed_point.o" doesn't exist Linking fixed_point Translating symbols for fixed_point Done ~/project/fixed_point_issue> simppc -ada fixed_point BASE_TYPE: 0.00000000000000 .. 1.00000000000000 SUB1_TYPE: 0.00000000000000 .. 0.50781250000000 SUB2_TYPE: 0.00000000000000 .. 0.50781250000000 SUB3_TYPE: 0.00000000000000 .. 0.50781250000000 ~/project/fixed_point_issue> gnatmake -f fixed_point gnatgcc -c fixed_point.adb gnatbind -x fixed_point.ali gnatlink fixed_point.ali ~/project/fixed_point_issue> ./fixed_point BASE_TYPE: 0.00000000000000 .. 0.99218750000000 SUB1_TYPE: 0.00000000000000 .. 0.50781250000000 SUB2_TYPE: 0.00000000000000 .. 0.39843750000000 SUB3_TYPE: 0.00000000000000 .. 0.50781250000000 -- 8< -- After all it really looks like the target compiler actually uses an Ada83 mode(l) here, although the code definitely is Ada95, and also both compilers claim to be Ada95 compilers. > It is difficult to say how the compiler could detect that. Well, it did. By raising Constraint_Error for an assignment of a value within the supposed range of the subtype. The virtues of unit testing. Fortunately, it wasn't the other way around. Vinzent. -- There is no signature.