mark@promark.UUCP (Mark J. DeFilippis) (09/16/89)
I was starting to port source for a version 7 Unix pascal compiler to
SCO XENIX 2.3.1 when I ran into a real weird problem. Isolating the line
which was the source of the error I found the following:
The following short section of code does not compile using SCO XENIX 2.3.1
and the 2.2.1 Development system, and I can't figure out why.
1 main()
2 {
3 char *cdecl;
4 }
Compiled with simple:
cc testfile.c
Yields the errors:
error(3) : error 59 : syntax error : ';'
***error code 1
If you change the name 'cdecl' to anything else, it compiles fine.
(ccdecl, cdecll, work fine, so the only thing I can think of is some
type of a conflict. But a conflict with what??? Their are no macros,
no external functions, no libraries, and the error it reports is a _syntax_
error of all things, not a linkage error.
Problems like this we don't need! Who thinks of changing variable names?
I mean, when you hit the point in your debugging that you are trying
to change the name of a variable as a hack, (Like the name should really
make a difference), it's a pretty desperate situation. This Unix
wizard thought he had seen it all... :-)
Can someone out there working with SCO xenix, and running a different release
try this little test program and let me know via email what the results are.
I also have an unconfirmed report that it bombs under the new SCO UNIX
release also.
Any constructive comments? Has this been seen before?
--
Adelphi University, Garden City, NY 11530 (516) 663-1170
Department of Mathematics and Computer Science
markd@adelphi.UUCP or mark@promark.UUCP
UUCP: ...philabs!sbcs!bnlux0!adelphi!markdchad@csd4.csd.uwm.edu (D. Chadwick Gibbons) (09/17/89)
In article <71@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes: |The following short section of code does not compile using SCO XENIX 2.3.1 |and the 2.2.1 Development system, and I can't figure out why. |1 main() |2 { |3 char *cdecl; |4 } The token "cdecl" is a reserved word under most implementations of compilers developed for the Intel familiy of processors. MicroSoft choosed to use this to determine if a given function name was a "pascal," "fortran," or C, i.e. "cdecl," function. This convenction is followed by most DOS compilers, and MicroSoft continues to use it--and they make the compilers for SCO XENIX. If you check the manual, there is a extended keyword flag introducing "pascal," "fortran," and "cdecl." -Me will turn on these flags. more than likely, your compiler will have "-M3e" or some such as the default flags. Defining your own defaults will remove this action.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/17/89)
In article <71@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes: >Any constructive comments? Has this been seen before? Yeah. Some MS/DOS C compilers think "cdecl" is a C keyword, meaning "use C linkage for this function even though a global compile switch says to use Pascal linkage". It's a crock. If you're lucky, you can do what on UNIX would be expressed as "cc -Dcdecl=Xcdecl" to work around the problem without having to do a lot of editing.
bill@twwells.com (T. William Wells) (09/17/89)
In article <71@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes:
: The following short section of code does not compile using SCO XENIX 2.3.1
: and the 2.2.1 Development system, and I can't figure out why.
:
: 1 main()
: 2 {
: 3 char *cdecl;
: 4 }
Cdecl is probably a modifier for functions that says that the
function uses the C calling sequence. You might find that the
identifiers "pascal" or "fortran" are also used this way.
Microsoft's C compilers for the IBM-PC (which I'm told are the same
as used in Xenix) do something like this. There is, for the Microsoft
compilers, a compiler option to disable this. Who knows, maybe there
is one for yours?
---
Bill { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.comjfh@rpp386.Dallas.TX.US (John F. Haugh II) (09/17/89)
In article <11101@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <71@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes: >>Any constructive comments? Has this been seen before? > >Yeah. Some MS/DOS C compilers think "cdecl" is a C keyword, >meaning "use C linkage for this function even though a global >compile switch says to use Pascal linkage". It's a crock. > >If you're lucky, you can do what on UNIX would be expressed as >"cc -Dcdecl=Xcdecl" to work around the problem without having >to do a lot of editing. This option can be turned off by editing /etc/default/cc and removing the 'e' from the FLAGS= line. [ Or he could add -Dcdecl=Xcdecl if he wants the other Intel extensions ] -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | It's not that important, InterNet: jfh@rpp386.cactus.org | it's only USENET. UUCPNet: {texbell|bigtex}!rpp386!jfh +-------------- -- Rich $alz ----
mark@promark.UUCP (Mark J. DeFilippis) (09/18/89)
In article <95@uwm.edu>, chad@csd4.csd.uwm.edu (D. Chadwick Gibbons) writes: > In article <71@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes: > |The following short section of code does not compile using SCO XENIX 2.3.1 > |and the 2.2.1 Development system, and I can't figure out why. > |1 main() > |2 { > |3 char *cdecl; > |4 } > > The token "cdecl" is a reserved word under most implementations of > compilers developed for the Intel familiy of processors. MicroSoft choosed to > use this to determine if a given function name was a "pascal," "fortran," or > C, i.e. "cdecl," function. I thank you for pointing me in the proper direction. Having worked mostly in the unix enviroment I am starting to get an appreciation of the the the portability problems going from a real UNIX environemnt to a xenix environment. > This convenction is followed by most DOS > compilers, and MicroSoft continues to use it--and they make the compilers for > SCO XENIX. If you check the manual, there is a extended keyword flag > introducing "pascal," "fortran," and "cdecl." -Me will turn on these flags. I will add, I did RTFM before the post, and the SCO manual for the release I am using notes the near, far, huge, pascal and fortran keywords ONLY. No mention is made of cdecl anywhere. ARGGGGGG! Even in the C reference syntax summary they note only the above listed identifiers may be keywords if the -Me flag is used. I should have known however that something like this was the cause. It seems they make their own standards. I should have known I was in trouble as soon as I saw the way they impliment variable number of parameters without even mentioning a portability issue exists. I hope that under SCO UNIX, these issues are eliminated. Mark DeFilippis -- Adelphi University, Garden City, NY 11530 (516) 663-1170 Department of Mathematics and Computer Science markd@adelphi.UUCP or mark@promark.UUCP UUCP: ...philabs!sbcs!bnlux0!adelphi!markd
tanner@cdis-1.uucp (Dr. T. Andrews) (09/19/89)
In article <71@promark.UUCP>, mark@promark.UUCP (Mark J. DeFilippis) writes:
) 3 char *cdecl;
The SCO (microsoft) compilers have added a few extra "reserved words".
Other examples:
s203948 Don't have a flag "interrupt" which is set by a signal handler.
Don't name your pascal input file "pascal".
It may not be wise to count on full ANSI C when __STDC__ is defined,
either.
--
...!bikini.cis.ufl.edu!ki4pv!cdis-1!tanner ...!bpa!cdin-1!cdis-1!tanner
or... {allegra attctc gatech!uflorida}!ki4pv!cdis-1!tanner