gwyn@smoke.BRL.MIL (Doug Gwyn) (10/08/90)
In article <125@alfrat.uucp> roy@alfrat.UUCP (Roy Phillips) writes:
-The standard header files supplied with AT&T's UNIX System V Release 4.2
-contains pre-processor commands such as the following:
- #if #machine(pdp11)
-The C preprocessor supplied has no problems with this, but my preferred C
-compiler, gcc, objects, even in it's '-ansi' mode. So I guess it's
-not ANSI C.
Correct -- This is a nonstandard extension, and any program using it
is not strictly conforming, meaning that it may be rejected by some
other (standard conforming) C compiler.
-My questions are::
-1. Does anyone know about this pre-processor syntax? and is it
- supposed to be standard on SysVR4?
Yes, in fact I think this was added around SVR3.2.
In my option, it was ill-conceived, and hinders application portability
rather than enhancing it.roy@alfrat.uucp (Roy Phillips) (10/08/90)
The standard header files supplied with AT&T's UNIX System V Release 4.2
contains pre-processor commands such as the following:
#if #machine(pdp11)
The C preprocessor supplied has no problems with this, but my preferred C
compiler, gcc, objects, even in it's '-ansi' mode. So I guess it's
not ANSI C.
My questions are::
1. Does anyone know about this pre-processor syntax? and is it
supposed to be standard on SysVR4?
2. Assuming yes to the above, is there a patch for 'gcc' to cater for it?
As well as the above, the organisation of the library directory has changed
somewhat - 'gcc' can't find 'crt0.o', which is now in /usr/ccs/lib, instead
of /usr/lib (the same goes for most of the libraries).
We've UCB compatabilty now, but what about System V compatabilty?
Many thanks for help, past & future!
--
Roy Phillips
A+F SystemEntwicklung
D-4030 Ratingen
West Germany
roy@alfrat.UUCP
{world}!mcsun!unido!alfrat!royfriedl@mtndew.Tustin.CA.US (Steve Friedl) (10/09/90)
In article <125@alfrat.uucp>, roy@alfrat.uucp (Roy Phillips) writes: > The standard header files supplied with AT&T's UNIX System V Release 4.2 > contains pre-processor commands such as the following: > > #if #machine(pdp11) > I think you mean the C Programming Utilities Issue 4.2 -- SVR4.2 isn't out yet. These are assertions, and they are intended to create a new namespace (!) for compile-time constants and things that are environment-specific. They are set with # assert foo # assert machine(pdp11) and tested with # if #foo # if #machine(pdp11) The # notation doesn't mess up any current syntaxes. The assertions can be turned on individually from the command line or all of the pre-asserted ones turned of en mas. The 3B2 ANSI compiler pre-asserts: #assert system(unix) #assert CPU(M32) #assert machine(u3b2) but there is no way to turn just one of these pre-asserts off from the command line (or at least there wasn't in the alpha version). I hope they have fixed this by now. Steve -- Stephen J. Friedl, KA8CMY / I speak for me only / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "No job is too big, no fee is too big" - Gary W. Keefe's company motto
rembo@unisoft.UUCP (Tony Rems) (10/11/90)
In article <125@alfrat.uucp> roy@alfrat.UUCP (Roy Phillips) writes: >The standard header files supplied with AT&T's UNIX System V Release 4.2 >contains pre-processor commands such as the following: > > #if #machine(pdp11) > >The C preprocessor supplied has no problems with this, but my preferred C >compiler, gcc, objects, even in it's '-ansi' mode. So I guess it's >not ANSI C. > >My questions are:: > >1. Does anyone know about this pre-processor syntax? and is it > supposed to be standard on SysVR4? > >2. Assuming yes to the above, is there a patch for 'gcc' to cater for it? > >As well as the above, the organisation of the library directory has changed >somewhat - 'gcc' can't find 'crt0.o', which is now in /usr/ccs/lib, instead >of /usr/lib (the same goes for most of the libraries). > 1. Yes, this is standard in the C Issue 5.0 which is provided with SVR4. This works through a pre-processor function that works like this: #define pdp11 1 #assert machine(pdp11) so, doing '#if #machine(pdp11)' (assuming the above declaration), indicates that the assertion is true. 2. I believe there is currently negotiation underway for GNU to work on a version of gcc and gdb for SVR4. As for you compatibility problem, I suggest symbolic links as a temporary hack. AT&T has decided that all the language development tools belong under /usr/ccs. Depending on what needs you have, you can #ifdef them out if you really need to use gcc. This way you can do something like: #ifdef ATT_CC #if #machine(pdp11) #else #ifdef GCC #do whatever checks you might need #endif It's a hack, but it should solve your problems. -Tony
rembo@unisoft.UUCP (Tony Rems) (10/12/90)
In article <3158@unisoft.UUCP> rembo@unisoft.UUCP (Tony Rems) writes: >In article <125@alfrat.uucp> roy@alfrat.UUCP (Roy Phillips) writes: >>The standard header files supplied with AT&T's UNIX System V Release 4.2 >>contains pre-processor commands such as the following: >> >> #if #machine(pdp11) >> >>The C preprocessor supplied has no problems with this, but my preferred C >>compiler, gcc, objects, even in it's '-ansi' mode. So I guess it's >>not ANSI C. >> >>My questions are:: >> >>1. Does anyone know about this pre-processor syntax? and is it >> supposed to be standard on SysVR4? >> >>2. Assuming yes to the above, is there a patch for 'gcc' to cater for it? >> >>As well as the above, the organisation of the library directory has changed >>somewhat - 'gcc' can't find 'crt0.o', which is now in /usr/ccs/lib, instead >>of /usr/lib (the same goes for most of the libraries). >> One more thing. Although I haven't confirmed this, it seem that the #if #machine construct *is* ANSI, but that gcc is not entirely ANSI (even with the -ansi option). -Tony
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/12/90)
In article <3159@unisoft.UUCP> rembo@unisoft.UUCP (Tony Rems) writes: >One more thing. Although I haven't confirmed this, it seem that >the #if #machine construct *is* ANSI, but that gcc is not >entirely ANSI (even with the -ansi option). Would you guys please quit cluttering the net with wild guesses? "#if #machine(...)" cannot be used in a strictly conforming C program. That is why I say that that whole approach is a botch. It's intended specifically to aid in porting across environments, but it interferes with porting to most environments!
meissner@osf.org (Michael Meissner) (10/12/90)
In article <3159@unisoft.UUCP> rembo@unisoft.UUCP (Tony Rems) writes: | One more thing. Although I haven't confirmed this, it seem that | the #if #machine construct *is* ANSI, but that gcc is not | entirely ANSI (even with the -ansi option). GCC does has a few dark corners, that are being fixed, though a lot of the problems are using the host library. However, the #if #machine construct is definately NOT ansi -- you must be thinking of the stringizing operator which is only allow within macro bodies. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
zoo@grumpy.spa.umn.edu (david d [zoo] zuhn) (10/13/90)
>>>>> On 11 Oct 90 22:31:24 GMT, rembo@unisoft.UUCP (Tony Rems) said:
[regarding the S5R4 #machine debate, which is this:
#assert #machine(pdp11)
#if #machine(pdp11)
...
#endif
Tony> One more thing. Although I haven't confirmed this, it seem that
Tony> the #if #machine construct *is* ANSI, but that gcc is not
Tony> entirely ANSI (even with the -ansi option).
I would say that it is NOT ansi legal, or at least there is NO mention
of #assert (a basic element of this mechanism) in the ANSI standard.
I couldn't find exact wording about additional preprocessing
directives being implementation defined, undefined, or what, but it's
not part of the Standard.
david d [zoo] zuhn Univ. of Minnesota Dept. of Astronomy
zoo@aps1.spa.umn.edu Automated Plate Scanner Projectbrowns@iccgcc.decnet.ab.com (Stan Brown, Oak Road Systems) (10/16/90)
In article <14132@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <3159@unisoft.UUCP> rembo@unisoft.UUCP (Tony Rems) writes: >>One more thing. Although I haven't confirmed this, it seem that >>the #if #machine construct *is* ANSI, but that gcc is not >>entirely ANSI (even with the -ansi option). > > Would you guys please quit cluttering the net with wild guesses? > "#if #machine(...)" cannot be used in a strictly conforming C program. > That is why I say that that whole approach is a botch. It's intended > specifically to aid in porting across environments, but it interferes > with porting to most environments! I thought things like this were why the gods gave us #pragma !? The above opinions are not attributable to any other person or company. email: browns@iccgcc.decnet.ab.com Stan Brown, Oak Road Systems, Cleveland, Ohio, U.S.A. +1 216 371 0043