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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public From: emery@grebyn.com (David Emery) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/03 Message-ID: #1/1 X-Deja-AN: 145535257 references: <31582A63.4BE9@east.thomsoft.com> <4jeel1$erh@tpd.dsccc.com> <4jp388$d56@tpd.dsccc.com> <828445854snz@genesis.demon.co.uk> <3161447e.494168937@news.dimensional.com> organization: MIND LINK! - British Columbia, Canada newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1996-04-03T00:00:00+00:00 List-Id: In article <3161447e.494168937@news.dimensional.com>, cjames@melchizedek.cec-services.com wrote: > emery@grebyn.com (David Emery) posted with deletions: > > | In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > | > | > ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. > | > Unix calls are reasonably standardised for C through the likes of POSIX and > | > X/Open which is natural because C is the core development language for > | > the platform. > | > > | > -- > | > ----------------------------------------- > | > Lawrence Kirby | fred@genesis.demon.co.uk > | > Wilts, England | 70734.126@compuserve.com > | > ----------------------------------------- > | > | This is not exactly true. The POSIX.1 standard make extensive use of > | facilities in the ANSI C standard. Chapter 2 contains a list of library > | calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 > | contains C-specific facilities, that refine the behavior of some ANSI > | C library routines such as file stream IO. > | > | dave > > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Colin James III, Principal Scientist cjames@cec-services.com > CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA > Voice: 303.231.9437; Facsimile: .231.9438 > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Of course, if CJ Disease knew anything about POSIX, then he would be aware of the dependence that all POSIX standards, including the Ada binding, implicitly have on facilities in ANSI C. Furthermore, each POSIX binding has a chapter for language-specific facilities, Chapter 8. The POSIX/Ada binding Chapter 8 covers the interpretation of Text_IO facilities in a POSIX context. In particular, it defines the syntax and semantics of the FORM parameter for Text_IO.Open and Text_IO.Create, allowing such things as Append mode, access to POSIX file descriptors, etc. The implicit dependency that each POSIX standard has on "the mother document", POSIX.1, and its relationship to ANSI C, is particularly important for multi- language programming, since it defines, for most current POSIX implementations, the underlying mechanisms used by the various languages. At some level, both C and Ada runtime systems have to allocate memory. It is important that these allocation systems be interoperable (so memory allocated from C can be read in Ada, and vice versa), and a common approach to doing this is to build the Ada allocator on top of, or at least in cooperation with, C's malloc(). So, CJ Disease, go bite a mad cow... dave