rvdp@cs.vu.nl (=Ronald van der Pol) (10/13/90)
tb@pemstgt.gtc.de (Tillmann Basien) writes: | Hy netlanders, | I have SCO UNIX Version 3.2.0 with Development Kit. | The atof()-function does not work proberly. Is there a work-a-round | of this problem? atof() **does** work normally | My test-programm: | #include <stdio.h> | #include <math.h> #include <stdlib.h> | main() | { | double f; | f=atof("123.23"); | printf("F: %f \n",f); | } SCO UNIX has an ANSI C compiler. ANSI C's atof() is decared in "stdlib.h". -- Ronald van der Pol <rvdp@cs.vu.nl>
jmc@teqsoft.UUCP (Jack Cloninger) (10/14/90)
rvdp@cs.vu.nl (=Ronald van der Pol) writes: >tb@pemstgt.gtc.de (Tillmann Basien) writes: >| I have SCO UNIX Version 3.2.0 with Development Kit. >| The atof()-function does not work proberly. Is there a work-a-round >| of this problem? >| > SCO UNIX has an ANSI C compiler. ANSI C's atof() is decared > in "stdlib.h". IMHO the problem here is documentation. The SCU Unix System V/386 Development System Programmer's Reference manual manual page for ATOF(S) gives the following syntax description: #include <math.h> double atof(nptr) char *nptr; The entry for "atoi" and "atol" give the correct include file, which is as Mr. van der Pol states, "stdlib.h." Mr. Basien did everything correctly according to the manual, but was simply bitten by a documentation error. -- Jack Cloninger, TeqSoft, 112 US Highway 1, Tequesta, FL 33469 B-) ...uunet!comtst!teqsoft!jmc Phone: 407-747-7163 Fax: 407-747-0354
em@dce.ie (Eamonn McManus) (10/19/90)
In article <7944@star.cs.vu.nl> rvdp@cs.vu.nl (=Ronald van der Pol) writes: > SCO UNIX has an ANSI C compiler. SCO Unix has a compiler that makes a feeble pretense at being ANSI. It's ridiculously inept in some areas. Look at the definition of offsetof() in <stddef.h> for example: it evaluates to a (char *) instead of an integer. I would advise anyone writing C programs on this system to get the GNU C compiler. -- Eamonn McManus <em@dce.ie> Are they the pearls of song Dropped by countless angel throng From paradise above? No.
bill@unixland.uucp (Bill Heiser) (10/20/90)
In article <orthodontist@dce.ie> em@dce.ie (Eamonn McManus) writes: > >I would advise anyone writing C programs on this system to get the GNU >C compiler. Although GCC itself is ANSI-compliant, what do people do about the non- ansi system library files like toupper, printf, and the rest? bill -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp bill%unixland.uucp@world.std.com Public Access Unix - Esix SYSVR3 - (508) 655-3848
seanf@sco.COM (Sean Fagan) (10/24/90)
In article <orthodontist@dce.ie> em@dce.ie (Eamonn McManus) writes: >SCO Unix has a compiler that makes a feeble pretense at being ANSI. It's >ridiculously inept in some areas. Look at the definition of offsetof() in ><stddef.h> for example: it evaluates to a (char *) instead of an integer. Actually, it evaluates to a void*, not a char*. (We forgot to put in the cast, it looks like; a simple enough fix if you run into problems with it, in this respect.) If you want to be more precice, it evaluates to a <type-of-member>*. >I would advise anyone writing C programs on this system to get the GNU >C compiler. Provided, of course, they don't want to be compatable with the system, that's a pretty decent suggestion. And, of course, they cannot develop DOS, '286, or OMF products using gcc. -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
ronald@robobar.co.uk (Ronald S H Khoo) (10/25/90)
In article <8372@scolex.sco.COM> seanf (Sean Fagan) writes: > they cannot develop DOS, '286, or OMF products using gcc. 386 OMF support is available with the Xenix GCC patch kit from steve@robobar.co.uk -- you knew that Sean! There are *lots* of people using GCC with Xenix, whose Dev Sys only speaketh OMF as you well know :-) There is no problem running Xenix 386 OMF GAS under sysv386 -- it remains my "standard" assembler because I need my binaries to remain Xenix compatible. For dross and 286, I agree, but who would want to anyway ? :-) -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)