Xref: utzoo comp.std.c:144 comp.lang.c:11213
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: Help me translate into C
Message-ID: <8223@brl-smoke.ARPA>
Date: 8 Jul 88 03:02:34 GMT
References: <11475@steinmetz.ge.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 31

In article <11475@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>First "pascal."

That indicates that a Pascal-compatible calling sequence is to be used
for the function so labeled.  This is normally needed only when using
externally-provided library routines compiled under Pascal.  If your
version of such routines have C-compatible interfaces, remove the
"pascal" keywords or #define them as nothing.

>Second "cdecl."

That indicates that a C-compatible calling sequence is to be used for
the function so labeled.  Just drop the "cdecl" keywords or #define
them as nothing.

>I know it [cdecl] was in dpANS briefly, ...

I don't think so; certainly not while I've been on the committee.
It would make no sense to include it in the C Standard, since it
would have to be a no-op.

>  A macro "SEEK_SET" as the third argument of lseek.

On any UNIX-compatible system this has to be defined as 0.

>  It also uses a few things like O_BINARY which means untranslated on
>systems having funny filetypes like DOS and VMS.

The ANSI C equivalent would be the "b" mode suffix for the various
standard I/O routines fopen(), freopen().  On any UNIX-compatible
system there is no distinction between text and binary file modes,
so O_BINARY can be removed (or #defined as 0).