Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!unmvax!bbx!russ From: russ@bbx.UUCP (Russ Kepler) Newsgroups: comp.lang.c Subject: Re: Weird problem with C compiler under SCO - I can't believe it! Summary: it's worse than that! Keywords: SCO C BUG Message-ID: <940@bbx.UUCP> Date: 26 Sep 89 14:57:32 GMT References: <71@promark.UUCP> <14561@bloom-beacon.MIT.EDU> Reply-To: russ@bbx.UUCP (Russ Kepler) Distribution: na Organization: BASIS International, Albuquerque NM Lines: 56 In article <14561@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) 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 } >> >>Yields the errors: >> error(3) : error 59 : syntax error : ';' >> >>[ rest deleted for brevity, turn out cdecl is a *keyword*] > >The problem, of course, is that in many PeeCee environments >"cdecl" is a new _keyword_, and keyword namespace pollution is >even more onerous than, say, external linkage namespace >pollution. > >Mark's comments perfectly express the exasperation which is >(properly) felt by anyone faced with a misguidedly "extended" >and therefore nonstandard environment. (No fair saying "but who >would ever name a variable 'cdecl?'." The same problem bit me, >when I wrote a version of the ever-popular cdecl program.) > But this isn't the worst; I couldn't port to a major European hardware platform because they decided that 'near' and 'far' weren't only keywords but that keywords that weren't yet implemented couldn't be redefined... can you say catch-22? After changing only 2500 lines of code (lets see now, sed(1), uh-huh, '-f', yep, 'for i in *.[ch]', there we go) the code will now compile. Then the *real* trouble starts. Lots of code in lots of libraries don't hide the entry points. 'movblk' seems rather more popular than it used to be, 'send' is great when you start including the socket libs (and using 'em). When I'm faced with one of the 'it's got to work!' situations I start looking for common named routines/variables in my code *and* the libs that are being included. A quick 'nm *.a | grep -v ...' to a comm and I can find the duplicate. A quick #define in the highest #include, a recompile and we're back in business... after a few hours of ranting, raving, etc. I wish that somewhere in /lib there was a file of all entry points in all of the libs - and a standard way of comparing with your code's entry points. Any pointers out there? -- Russ Kepler - Basis International SNAILMAIL: 5901 Jefferson NE, Albuquerque, NM 87109 UUCP: {backboneishsite}!unmvax!bbx!russ PHONE: 505-345-5232