1 INFO-VAX	Mon, 25 Jul 2005	Volume 2005 : Issue 412       Contents: Re: another CXX question Re: another CXX question Re: another CXX question Re: another CXX question Re: another CXX question6 Re: Anyone Using Multinet NFS to access CMS Libraries?6 Re: Anyone Using Multinet NFS to access CMS Libraries?N Re: Building SIMH V3.4 on OpenVMS Alpha V7.3-2 / CC V6.5 - errors - any ideas?# Re: CMS$EVENT_ACTION does not work. & Re: DEC Forms Calender and Time Panels Printronix P600:  Any Interest? " Re: simple image processing on VMS" Re: simple image processing on VMS" Re: simple image processing on VMS Re: uptimes  Re: uptimes  Re: uptimes 9 [OT] Rounding v Truncation, was: Re: Platform Support vs. = Re: [OT] Rounding v Truncation, was: Re: Platform Support vs.   F ----------------------------------------------------------------------  % Date: Mon, 25 Jul 2005 05:22:41 -0400 + From: Chip Coldwell <coldwell@gmail.nospam> ! Subject: Re: another CXX question E Message-ID: <Pine.LNX.4.63.0507250522340.10769@localhost.localdomain>   , On Sun, 24 Jul 2005, John E. Malmberg wrote:   > Chip Coldwell wrote: >>   > $ cxx/version / >> Compaq C++ V6.5-046 for OpenVMS Alpha V7.3-1  >> $ cxx foo.cc  >> >>       if (neg) 
 >> ......^3 >> %CXX-W-CODEUNREACHABLE, statement is unreachable 9 >> at line number 54 in file DISK$USER:[COLDWELL]FOO.CC;8  > J > There should be a #pragma that you can put in an architecture or system 0 > specific header file to suppress this warning.  D You don't understand: the problem isn't the warning.  The problem is@ that the generated code is incorrect.  That code should *NOT* be unreachable.   Chip   --   Charles M. "Chip" Coldwell Turn on, log in, tune out    ------------------------------  # Date: Mon, 25 Jul 2005 13:30:52 GMT 7 From: John Malmberg <malmberg@dskwld.zko.dec.compaq.hp> ! Subject: Re: another CXX question 2 Message-ID: <gQ5Fe.9161$fZ4.8055@news.cpqcorp.net>   Chip Coldwell wrote:  >G  > You don't understand: the problem isn't the warning.  The problem is C  > that the generated code is incorrect.  That code should *NOT* be   > unreachable.   @ It is coded so that it is unreachable so the warning is correct.   Chip Coldwell wrote: > 9 > The following code is excerpted from the lexer in Xpdf:  >  > #include <ctype.h> > #include <stdio.h> > " > int main(int argc, char *argv[]) > {   >   const char *str = "3.14159";  2 Note that input data is known, small and constant.   >   int c, xi; >   double xf, scale; 
 >   bool neg;  >  >   while(c = *str++) {   I You coded a loop to handle constant data, the compiler probably unrolled  B the loop for faster processing in the optimizer, because it could * eliminate the conditionals and other code.   >     switch (c) { > 7 >     case '0': case '1': case '2': case '3': case '4': 7 >     case '5': case '6': case '7': case '8': case '9':  >     case '-': case '.':  >       neg = false; >       xi = 0;  >       if (c == '-') {  >         neg = true;  >       } else if (c == '.') { >         goto doReal; >       } else { >         xi = c - '0'; 	 >       }  >       while (1) {  >         c = str[1];  >         if (isdigit(c)) {  >           str++;% >           xi = xi * 10 + (c - '0');   >         } else if (c == '.') { >           str++; >           goto doReal; >         } else { >           break; >         } 	 >       }  >       if (neg) >         xi = -xi; + >       printf("integer value = %d\n", xi);  >       break;  G At this point ends the only path where the value of neg is set to true.   G The compiler knows from the value const str that neg will never be set  6 to true, so it can optimize all references to it away.  
 >     doReal:   F If str were being passed to this routine instead of a local constant, C then you have an uninitialized variable condition below.  On the C  H compiler with /WARN=ENABLE=(LEVEL4, QUESTCODE), I would have expected a C diagnostic about that at the first time the value of neg is needed.   D But the compiler knows that neg will always be false because it has 1 already optimized the loop for the constant data.    >       xf = xi; >       scale = 0.1; >       while (1) {  >         c = str[1];  >         if (!isdigit(c)) { >           break; >         }  >         str++;& >         xf = xf + scale * (c - '0'); >         scale *= 0.1; 	 >       }   C To get here, neg may not have been initialized if str had not been  . constant as far as the compiler was concerned.   >       if (neg) >         xf = -xf; 2 >       printf("floating-point value = %d\n", xf); >       break; >  >     default:& >       puts("non-numeric character"); >       break; >     }  >   }  >   puts("done lexing"); > }  > 9 > When compiled with no options, it generates this error:  >  > $ cxx/version . > Compaq C++ V6.5-046 for OpenVMS Alpha V7.3-1 > $ cxx foo.cc >  >       if (neg)	 > ......^ 2 > %CXX-W-CODEUNREACHABLE, statement is unreachable8 > at line number 54 in file DISK$USER:[COLDWELL]FOO.CC;8  G Default optimization level probably removed your loop and wrote inline  $ code to generate he expected result.  L > And the compiler really means it -- it optimizes out the unreachable code.  ( It is correct.  The code is unreachable.  J > The line the compiler is complaining about is the one at the end of the H > "while(1)" loop under the "doReal:" label where the lexer is lexing a K > floating-point number.  There's all kinds of fishy things going on there  J > (jumping to a goto-label in the middle of a bunch of switch-labels?!?),   ! Legal and in the C specification.   H > but nonetheless I think the C++ standard requires that the "break" in M > the "while(1)" loop should break out of the loop, not the enclosing switch.   / By now you know that you missed something else.    > I fixed the problem thus:  > 
 >     doReal:  >       xf = xi; >       scale = 0.1; >       while (1) {  >         c = str[1];  >         if (!isdigit(c)) { >           goto doneReal; >         }  >         str++;& >         xf = xf + scale * (c - '0'); >         scale *= 0.1; 	 >       }  >     doneReal:  >       if (neg) >         xf = -xf; 2 >       printf("floating-point value = %d\n", xf); >       break;  H That may have removed the diagnostic, but neg will never be set because I str is constant, and the compiler optimizer has converted your algorithm    to match the special case input.  I I suspect that this is a sample program to try to isolate a problem, and  4 that the const str does not represent the real data.  H If str was a passed parameter, as far as the compiler knows, you have a G potentially uninitialized variable "neg" being referenced and with the  8 warning level set high enough, it should be complaining.  H > and now I have a working Xpdf v3.00pl3 (compiled with Freetype 2.1.10 5 > and T1Lib 5.0.2 -- stay tuned for an announcement).   & Are you still sure that it is working?   -John ! malmberg@dskwld.zko.dec.compaq.hp  Personal Opinion Only    ------------------------------  % Date: Mon, 25 Jul 2005 10:25:50 -0400 + From: Chip Coldwell <coldwell@gmail.nospam> ! Subject: Re: another CXX question P Message-ID: <Pine.OSX.4.62.0507251022560.214@physics-departments-computer.local>  ) On Mon, 25 Jul 2005, John Malmberg wrote:    > Chip Coldwell wrote: >>G >> You don't understand: the problem isn't the warning.  The problem is C >> that the generated code is incorrect.  That code should *NOT* be  >> unreachable.  > B > It is coded so that it is unreachable so the warning is correct.  D You're right, however the program that it was excerpted from did notD have a constant string and generated the same warning.  Try changing        const char *str = "3.14159";   to       char *str = argv[1];  B and see if you get the same warning (I would do it myself, but I'm away from my cluster).  M >> and now I have a working Xpdf v3.00pl3 (compiled with Freetype 2.1.10 and  2 >> T1Lib 5.0.2 -- stay tuned for an announcement). > ( > Are you still sure that it is working?  F Yes, absolutely.  I traced the execution with the debugger down to theE problem at this line in the lexer where the proper code path had been  optimized away.    Chip   --   Charles M. "Chip" Coldwell Turn on, log in, tune out    ------------------------------  # Date: Mon, 25 Jul 2005 15:50:15 GMT 7 From: John Malmberg <malmberg@dskwld.zko.dec.compaq.hp> ! Subject: Re: another CXX question 2 Message-ID: <XS7Fe.9179$a95.8522@news.cpqcorp.net>   Chip Coldwell wrote:+ > On Mon, 25 Jul 2005, John Malmberg wrote:  > C >> It is coded so that it is unreachable so the warning is correct.  >   F > You're right, however the program that it was excerpted from did notF > have a constant string and generated the same warning.  Try changing > ! >    const char *str = "3.14159";  >  > to >  >    char *str = argv[1];  > D > and see if you get the same warning (I would do it myself, but I'm > away from my cluster).  > As I previously stated, I would expect that you should get an > uninitialized variable warning, not an optimized away warning.  F But I could be wrong, as this code is a bit complex with the branches.  G This could be an optimizer bug, or it could be something that I am not   seeing.   I I have not yet found a case in code I was working on where an unexpected  F optimized away warning was not hiding a bug in the code, as much as I $ would have liked it to be otherwise.  C I would recommend increasing the level of diagnostics that the CXX  D compiler generates to see if something more precise shows up in the  error message.  8 For C, that would be "/WARN=ENABLE=(LEVEL4, QUESTCODE)".  J >>> and now I have a working Xpdf v3.00pl3 (compiled with Freetype 2.1.10 7 >>> and T1Lib 5.0.2 -- stay tuned for an announcement).  >>) >> Are you still sure that it is working?  > H > Yes, absolutely.  I traced the execution with the debugger down to theG > problem at this line in the lexer where the proper code path had been  > optimized away.   I I would recommend fixing the potentially uninitialized variable "neg" in  H the original code to be initialized to zero and see if the warning goes  away.   I Since a human would expect that "str" would always have a digit or a "."  H so that the first branch of the case statement would always set a valid > value to "neg", the value of "neg" does not seem to really be ' uninitialized when it is actually used.   E But the compiler may be seeing cases where "neg" could be referenced   before it is set.   H Your replacement code may be more correct and better for the optimizer. F   It looks like that for some reason you are implementing the code in 	 sscanf().   H The compiler also knows how to inline sscanf() when the format string is known at compile time.   -John ! malmberg@dskwld.zko.dec.compaq.hp  Personal Opinion Only    ------------------------------  # Date: Mon, 25 Jul 2005 16:43:11 GMT 4 From: "Ed Vogel" <edward.vogel_stop_the_spam@hp.com>! Subject: Re: another CXX question 2 Message-ID: <zE8Fe.9180$o95.5743@news.cpqcorp.net>  9 "Chip Coldwell" <coldwell@gmail.nospam> wrote in message  ; news:Pine.LNX.4.61.0507241901080.13407@frank.harvard.edu...   E     I've read the replies here, and at first I was quite certain that      John Malmberg was correct.  B     However, it does seem like there is a compiler bug here.  I've;     reduced Chip's program to the one enclosed below.  This =     should output "here I am", and it does when compiled with ;     the C compiler.  The C++ compiler emits nothing.  Using      the /NOOPT does not help.        We'll have a look.       Ed Vogel$     HP/Compaq/DEC C/C++ Engineering.   extern #if __DECCXX     "C"  #endif     int printf(char *a,...); char *str = ".";
 int main() { 
     int c;     while(c = *str++) {        switch (c) {       case '.':          if (c == '.') {            goto doReal;	         }          break;
       doReal:          while (1) {            if (c != '1') {              break;           } 	         }          printf("here I am\n");         break;       }      }   }   ------------------------------    Date: 25 Jul 2005 08:11:25 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ? Subject: Re: Anyone Using Multinet NFS to access CMS Libraries? 3 Message-ID: <T+r5XkWGZhlO@eisner.encompasserve.org>   Z In article <969999405wspenceraporg@216.168.3.30>, wspe....@ap.org (Warren Spencer) writes: > M > Thanks Hoff.  Maybe I misunderstood this, but I thought Multinet's NFS was  L > equivalent to DFS.  The CMS docs say (for the vms command-line client) to N > use DFS (rather than simple remote network access) because the file locking D > that is neccessary CMS library access is not available without it.  E    DFS and NFS are very different protocols with very different ideas D    of what "file locking" is.  I would not use CMS on NFS, no matter    who's stack you buy.   D    Once upon a time CMS worked over DECnet without DFS.  Once upon aB    time it was broken and somebody planned to fix it.  I use it inD    a VMScluster, and I would consider the available client programs.  =    If I had to go IP then I'd use a non-VMS server and use an A    IP based tool like CVS (or do the CVS server port for us, it's :    a fork() based tool.)  The CVS client runs fine on VMS.             ------------------------------    Date: 25 Jul 2005 08:14:18 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ? Subject: Re: Anyone Using Multinet NFS to access CMS Libraries? 3 Message-ID: <qMsHOOa3cYAW@eisner.encompasserve.org>   f In article <11e1fu0946r60d0@corp.supernews.com>, "C.W.Holeman II" <cwhii_googlespam@yahoo.com> writes: > Warren Spencer wrote:  > 8 >> The CMS docs say (for the vms command-line client) toF >> use DFS (rather than simple remote network access) because the fileM >> locking that is neccessary CMS library access is not available without it.  >  > There is a DFS on VMS?  F    DECnet File System (IIRC).  Not the Windows DFS or the other common#    DFS who's first name escapes me.    ------------------------------  # Date: Mon, 25 Jul 2005 13:49:19 GMT A From: "Colin Butcher" <colin_DOT.butcher_AT@xdelta_DOT.co_DOT.uk> W Subject: Re: Building SIMH V3.4 on OpenVMS Alpha V7.3-2 / CC V6.5 - errors - any ideas? = Message-ID: <z56Fe.76790$G8.24624@text.news.blueyonder.co.uk>   L Thanks to all who replied. It's now working after changes to the DESCRIP.MMSK file and the [.PCAP-VMS.PCAP-VCI]SNPRINTF.C file. I've also chosen to use a H logical name SIMHDIR defined to the top level of the SIMH directory tree% rather than use the SYS$DISK logical.   > I've consolidated the fixes and a command file to build it allL (000BUILD.COM) on OpenVMS Alpha V7.3-2 (or V7.3-1 with the C RTL fixes) intoK a ZIPped saveset at http://www.downloads.xdelta.co.uk/simh034a/SIMH034A.ZIP    --     Hope this helps, Colin. ) colin DOT butcher AT xdelta DOT co DOT uk E It's not mine, but I like this definition: Legacy = stuff that works.    ------------------------------    Date: 25 Jul 2005 01:51:39 -0700+ From: "dreherthomi" <tdreher@economweb.com> , Subject: Re: CMS$EVENT_ACTION does not work.C Message-ID: <1122281499.076103.222980@f14g2000cwb.googlegroups.com>    Hello David,# thank you very much for your reply. @ As you have correctly guessed, I had to create IFM_CMS_EVENT.EXEB as a shareable image, and also had to create a system logical name= IFM_CMS_EVENT to point to this image, if it is not located in 
 sys$share.  1 Here is the link commandfile as suggested by you,  to produce the shareable image: 
 $ set noon! $ linkk/share=ifm_cms_event.exe - &          /map=ifm_cms_event.map/full -          /nodebug -           /notraceback -           /nonative_only -           /sysexe=selective -          sys$input/options  %          gsmatch         = lequal,1,0 !          ident           = "V1.0"   9          symbol_vector = ( CMS$EVENT_ACTION = procedure )             ifm_cms_event.obj( $ library/create/share ifm_cms_event.olb- $ library ifm_cms_event.olb ifm_cms_event.exe 	 $ exitt 1      Thanks again, regards - Thomas   ------------------------------    Date: 25 Jul 2005 08:22:09 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) / Subject: Re: DEC Forms Calender and Time Panels 3 Message-ID: <febOKuUFIMqg@eisner.encompasserve.org>   [ In article <67idnXAy_NfWrXzfRVn-pg@netnitco.net>, "Earl Lakia" <elakia@hotmail.com> writes: A > Anyone developed a Calender Panel or Clock panel for DEC Forms? F > Something similar to what is available in the Visual Basic and other > Microsoft  > Environments?  > F > I can't justify writing my own, and it's ok to call me lazy as I am.  E    Does it have to be in forms, or can you use the X-windows versions     that ship with VMS?   ------------------------------  # Date: Mon, 25 Jul 2005 15:04:02 GMT / From: Jeff Shirley <spam-aholic@mindspring.com> ( Subject: Printronix P600:  Any Interest?B Message-ID: <Cb7Fe.4604$Uk3.4319@newsread1.news.pas.earthlink.net>  
 Greetings.  L I have a Printronix P600 line printer that is taking up too much space in myN garage.  I think DEC sold these rebadged as LXY(something).  I have had it forC about eight years, but never done anything with it but power it up.   K My current plan is to scrap it and scavenge various parts, but I would also L consider letting it go to a good home (someone that wants to actually try toL use it).  It would need to be picked up from ZIP code 91786, with a truck or van.  D Send email to bucky (at) mindspring (dot) com if you are interested.   Jeff.  --   Jeff Shirley spam-pizza@mindspring.com O "Bill Gates is filthy rich, but that doesn't mean I want to be married to him."    ------------------------------  % Date: Mon, 25 Jul 2005 08:25:23 -0500 . From: Alphaman <alphaman-nix-spam@alphant.com>+ Subject: Re: simple image processing on VMS 7 Message-ID: <747b8$42e4e843$186088ed$21694@KNOLOGY.NET>    Peter Weaver wrote:   M > This worked for me with Compaq C V6.5-001 on OpenVMS Alpha V8.2. Assuming I 0 > did not miss any steps it should work for you; .  .  .  > Peter Weaver    H By "repeat", I presume you mean something like DCLwild?  I'll give this I a whirl -- it sure looks a lot easier than the other stuff I've seen and   tried!   THANKS!  Aaron    ------------------------------  % Date: Mon, 25 Jul 2005 08:23:16 -0500 . From: Alphaman <alphaman-nix-spam@alphant.com>+ Subject: Re: simple image processing on VMS 7 Message-ID: <8e91a$42e4e7c4$186088ed$21694@KNOLOGY.NET>     VAXman- @SendSpamHere.ORG wrote:9 > What are you using for a camera?  How big are your pix?   G Sony Mavica CD400.  I can take the images straight from CD to my Alpha   when I need to.   F I wonder if it's the JPEG vs. JPEG2000 that's left out of the earlier  version of ImageMagick.    Cheers & best regards, Aaron    ------------------------------  % Date: Mon, 25 Jul 2005 11:05:07 -0400 4 From: "Peter Weaver" <newsgroup@weaverconsulting.ca>+ Subject: Re: simple image processing on VMS + Message-ID: <3kkdd5FurtcuU1@individual.net>    Alphaman wrote:  > Peter Weaver wrote:  > C >> This worked for me with Compaq C V6.5-001 on OpenVMS Alpha V8.2. < >> Assuming I did not miss any steps it should work for you; > .  > .  > .  >> Peter Weaver  >  > D > By "repeat", I presume you mean something like DCLwild?  I'll giveF > this a whirl -- it sure looks a lot easier than the other stuff I've > seen and tried!  > 	 > THANKS!  > Aaron   3 DCLwild is probably the same idea as my REPEAT.COM.   ? But I did forget to mention that this does not handle your MPEG 
 requirements.    --   Peter Weaver Weaver Consulting Services Inc.  Canadian VAR for CHARON-VAX  www.weaverconsulting.ca    ------------------------------  % Date: Mon, 25 Jul 2005 09:39:40 -0600 + From: John Nebel <john.nebel_vms@csdco.com>  Subject: Re: uptimes( Message-ID: <42E507BC.7030708@csdco.com>  G At this time, probably temporary - it's not unusual to see it disappear  on occasion.  E BTW, there are two options for "connectivity" - UDP and TCP.  Use UDP E whenever possible.  There are many "inactive" VMS entries which might  benefit from this information.   --   Bradford J. Hamilton       Brad,   G UPD didn't seem to work - a tcptrace showed that an ICMP type 3 packet  E (unreachable) was being returned.  The format of the outgoing packet  & looked fine.  HTTP worked immediately.  E ping to 67.15.12.81 works, but not traceroute which makes one wonder   whether whatever is beyond  I 15  gphou-66-98-241-125.ev1.net (66.98.241.125)  64.4 ms (ttl=53!)  64.4   ms (ttl=53!)  65.4 ms (ttl=53!)   
 has a filter.     ' The entry on the uptimes page is "Hera"    John   ------------------------------    Date: 25 Jul 2005 09:27:30 -0700 From: jordan@ccs4vms.com Subject: Re: uptimesC Message-ID: <1122308850.616806.306880@g49g2000cwa.googlegroups.com>   C I was going to join the uptime project this weekend; my hobby AS600 E webserver box had been up for around 220 days; not a lot (and not its G record by far) since I had unplugged it to do power consumption testing A with a kill-a-watt meter some time ago.  Unfortunately we had a 8 G minute long brownout followed by a 5 minute blackout yesterday, and the C UPS came up about 2 minutes short.  Poof.  So I'm not going to pull 3 down the averages by joining, at least for a while.   @ The systems at work apparently had the same issue; they were all> freshly restarted last night, so no joy there either.  Sigh...     Rich   ------------------------------  % Date: Mon, 25 Jul 2005 13:33:25 -0400 6 From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> Subject: Re: uptimes0 Message-ID: <Fcidndn49ej4v3jfRVn-og@comcast.com>   John Nebel wrote:     >Brad,   I  >UPD didn't seem to work - a tcptrace showed that an ICMP type 3 packet  G  >(unreachable) was being returned.  The format of the outgoing packet  (  >looked fine.  HTTP worked immediately.  I Perhaps I had it backwards - yes, I was looking at the wrong file.  I am   indeed using http.   <snip>  )  >The entry on the uptimes page is "Hera"      Good to see it's working...        --   Bradford J. Hamilton "All opinions are my own" * "Lose the MAPS, and replace '-at-' with @"   ------------------------------    Date: 25 Jul 2005 07:52:36 -0500B From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)B Subject: [OT] Rounding v Truncation, was: Re: Platform Support vs.3 Message-ID: <Jxe3kcD7RYKM@eisner.encompasserve.org>   Z In article <11e6169idjh2n3a@corp.supernews.com>, Dave Froble <davef@tsoft-inc.com> writes: > F > When I had a problem with Visual Basic she defended VB and wouldn't J > consider it wrong.  So I'll ask, actually maybe take a poll.  If a real I > value is placed into an integer variable, how many people would expect  I > the fraction to be truncated?  I'd expect most would.  I did.  VAX/DEC  D > BASIC truncates.  Well, VB rounds, and fractional parts of .5 and H > greater round up.  Sure screwed with the logic from the converted VAX 1 > Basic applications.  Sure screwed with my mind.  >   M I would regard rounding to be the correct thing to do from a maths viewpoint.   B However, I created two examples, one in Ada and another in C which8 exhibit different behaviour. Ada rounds and C truncates:  % [simon@?????? ft]# cat float_test.adb  with Text_IO; use Text_IO;   procedure float_test is             Target:         Integer;         Source:         Float;   begin          Source := 3.4;"         Target := Integer(Source);H         Put_Line("Source = " & Source'Img & ", Target = " & Target'Img);           Source := 3.5;"         Target := Integer(Source);H         Put_Line("Source = " & Source'Img & ", Target = " & Target'Img);           Source := 3.6;"         Target := Integer(Source);H         Put_Line("Source = " & Source'Img & ", Target = " & Target'Img); end float_test;  [simon@?????? ft]# ./float_test " Source =  3.40000E+00, Target =  3" Source =  3.50000E+00, Target =  4" Source =  3.60000E+00, Target =  4P [simon@?????? ft]# cat float_test.c                                              #include <stdio.h>  
 int main()	         {          int target;          float source;            source = 3.4;          target = source;=         printf("Source = %f, target = %d\n", source, target);            source = 3.5;          target = source;=         printf("Source = %f, target = %d\n", source, target);            source = 3.6;          target = source;=         printf("Source = %f, target = %d\n", source, target);            return(0);	         } ! [simon@?????? ft]# ./float_test_c  Source = 3.400000, target = 3  Source = 3.500000, target = 3  Source = 3.600000, target = 3  [simon@?????? ft]#    L The Ada behaviour is specified in the Ada Language Reference Manual (section> 4.6, line 33), see: http://www.adapower.com/rm95/RM-4-6.html :  D 	If the target type is an integer type and the operand type is real,@ 	the result is rounded to the nearest integer (away from zero if( 	exactly halfway between two integers).    Simon.   --  B Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       7 Microsoft: The Standard Oil Company of the 21st century    ------------------------------  % Date: Mon, 25 Jul 2005 06:26:27 -0700 # From: "Tom Linden" <tom@kednos.com> F Subject: Re: [OT] Rounding v Truncation, was: Re: Platform Support vs.( Message-ID: <opsug0ydnqzgicya@hyrrokkin>  . On 25 Jul 2005 07:52:36 -0500, Simon Clubley  5 <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:   @ > In article <11e6169idjh2n3a@corp.supernews.com>, Dave Froble   > <davef@tsoft-inc.com> writes:  >>F >> When I had a problem with Visual Basic she defended VB and wouldn'tJ >> consider it wrong.  So I'll ask, actually maybe take a poll.  If a realI >> value is placed into an integer variable, how many people would expect I >> the fraction to be truncated?  I'd expect most would.  I did.  VAX/DEC D >> BASIC truncates.  Well, VB rounds, and fractional parts of .5 andH >> greater round up.  Sure screwed with the logic from the converted VAX2 >> Basic applications.  Sure screwed with my mind. >> > F > I would regard rounding to be the correct thing to do from a maths   > viewpoint. > D > However, I created two examples, one in Ada and another in C which: > exhibit different behaviour. Ada rounds and C truncates: > ' > [simon@?????? ft]# cat float_test.adb  > with Text_IO; use Text_IO; >  > procedure float_test is  > " >         Target:         Integer;  >         Source:         Float; >  > begin  >         Source := 3.4;$ >         Target := Integer(Source);J >         Put_Line("Source = " & Source'Img & ", Target = " & Target'Img); >  >         Source := 3.5;$ >         Target := Integer(Source);J >         Put_Line("Source = " & Source'Img & ", Target = " & Target'Img); >  >         Source := 3.6;$ >         Target := Integer(Source);J >         Put_Line("Source = " & Source'Img & ", Target = " & Target'Img); > end float_test; ! > [simon@?????? ft]# ./float_test $ > Source =  3.40000E+00, Target =  3$ > Source =  3.50000E+00, Target =  4$ > Source =  3.60000E+00, Target =  4% > [simon@?????? ft]# cat float_test.c  > #include <stdio.h> >  > int main() >         {  >         int target;  >         float source;  >  >         source = 3.4;  >         target = source;? >         printf("Source = %f, target = %d\n", source, target);  >  >         source = 3.5;  >         target = source;? >         printf("Source = %f, target = %d\n", source, target);  >  >         source = 3.6;  >         target = source;? >         printf("Source = %f, target = %d\n", source, target);  >  >         return(0); >         } # > [simon@?????? ft]# ./float_test_c  > Source = 3.400000, target = 3  > Source = 3.500000, target = 3  > Source = 3.600000, target = 3  > [simon@?????? ft]# > G > The Ada behaviour is specified in the Ada Language Reference Manual   
 > (section@ > 4.6, line 33), see: http://www.adapower.com/rm95/RM-4-6.html : > F > 	If the target type is an integer type and the operand type is real,B > 	the result is rounded to the nearest integer (away from zero if) > 	exactly halfway between two integers).  >  > Simon. > C Every programming language has it's own set of rules for implicit    conversion. = some more consistent than others.  PL/I for example truncates  FREJA> create rnd_trnc.pli test: proc options(main);  dcl f fixed dec(3,1);  dcl i fixed bin(15); do f = 3.4 to 3.6 by .1;
     i = f;     put skip list(i);      end;	 end test;  *EXIT* FREJA> pli rnd_trnc  FREJA> FREJA> link rnd_trnc FREJA> run rnd_trnc   
          3
          3
          3   ------------------------------   End of INFO-VAX 2005.412 ************************                                                                                                                                                                                                                                                                                  @+N    A+N    B+N    C+N    D+N    E+N    F+N    G+N    H+N    I+N    J+N    K+N    L+N    M+N    N+N    O+N    P+N    Q+N    R+N    S+N    T+N    U+N    V+N    W+N    X+N    Y+N    Z+N    [+N    \+N    ]+N    ^+N    _+N    `+N    a+N    b+N    c+N    d+N    e+N    f+N    g+N    h+N    i+N    j+N    k+N    l+N    m+N    n+N    o+N    p+N    q+N    r+N    s+N    t+N    u+N    v+N    w+N    x+N    y+N    z+N    {+N    |+N    }+N    ~+N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    ¸+N    ø+N    ĸ+N    Ÿ+N    Ƹ+N    Ǹ+N    ȸ+N    ɸ+N    ʸ+N    ˸+N    ̸+N    ͸+N    θ+N    ϸ+N    и+N    Ѹ+N    Ҹ+N    Ӹ+N    Ը+N    ո+N    ָ+N    ׸+N    ظ+N    ٸ+N    ڸ+N    ۸+N    ܸ+N    ݸ+N    ޸+N    ߸+N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N     +N    +N    +N    +N    +N    +N    +N    +N    +N    	+N    
+N    +N    +N    
+N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N     +N    !+N    "+N    #+N    $+N    %+N    &+N    '+N    (+N    )+N    *+N    ++N    ,+N    -+N    .+N    /+N    0+N    1+N    2+N    3+N    4+N    5+N    6+N    7+N    8+N    9+N    :+N    ;+N    <+N    =+N    >+N    ?+N    @+N    A+N    B+N    C+N    D+N    E+N    F+N    G+N    H+N    I+N    J+N    K+N    L+N    M+N    N+N    O+N    P+N    Q+N    R+N    S+N    T+N    U+N    V+N    W+N    X+N    Y+N    Z+N    [+N    \+N    ]+N    ^+N    _+N    `+N    a+N    b+N    c+N    d+N    e+N    f+N    g+N    h+N    i+N    j+N    k+N    l+N    m+N    n+N    o+N    p+N    q+N    r+N    s+N    t+N    u+N    v+N    w+N    x+N    y+N    z+N    {+N    |+N    }+N    ~+N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    ¹+N    ù+N    Ĺ+N    Ź+N    ƹ+N    ǹ+N    ȹ+N    ɹ+N    ʹ+N    ˹+N    ̹+N    ͹+N    ι+N    Ϲ+N    й+N    ѹ+N    ҹ+N    ӹ+N    Թ+N    չ+N    ֹ+N    ׹+N    ع+N    ٹ+N    ڹ+N    ۹+N    ܹ+N    ݹ+N    ޹+N    ߹+N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    +N    