From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: SAS/6.0 Bugs...
Originator: walker@twix.unx.sas.com
Date: Mon, 5 Oct 1992 14:01:25 GMT
Organization: SAS Institute Inc.


These questions/problems might be more appropriate to cover with
SAS/C technical support, but I suppose others might run into the
same problem so I'll answer them here.

In article <1992Oct3.022958.15200@cbnewsc.cb.att.com>, gregg@cbnewsc.cb.att.com (gregg.g.wonderly) writes:
|> I found the following problem in SAS/6.0.
|> 
|> 	    An #undef of a symbol in a .c file which is being used to
|>             create a GST results in that symbol always being undefined
|>             even if it is redfined in that file.  If main.c contains
|> 	    the following
|> 
|> 		#include <stdio.h>
|> 		#undef NULL
|> 		#define	NULL 0
|> 
|> 		#include "file.c"
|> 
|> 	    "file.c" contains a usage of NULL.  When compiling, the
|> 	    reference in file.c will result in an undefined symbol
|> 	    error.  

GSTs have a limited ability to mimic standard C include files.  They
are NOT always what you would get by simply compiling the file!
#undefs and conditional compilation tend to throw them for a loop.

In particular, when creating a GST the compiler ONLY pays attention
to .h files (not the .c file used).  This is so that some #define
or structure definition in the .c file does not affect the contents
of the GST, and therefore show up in every other .c file in your
project.  If you put the #undef in a .h file, it would take effect
in the GST, but ALL users of the GST would see the new value, which
may not be what you want.

Furthermore, you CANNOT DEFINE DATA ITEMS OR FUNCTIONS in a GST.
You can declare them, but not define them.  Therefore, if your
"file.c" above contains function definitions, no code will be
produced for them!

|> I have a couple of suggestions for enhancements too.  scmsg should take
|> vanilla key events and pass them to the arexx port too.

I'm not sure what this means.  I can't pass individual keystrokes
through to the AREXX port - the editor on the other end wouldn't
know how to interpret them.

|> With all of the PD makes and diffs available, why in the world are
|> smake and diff part of the distribution?  diff, in particular is
|> pretty much useless with tools such as patch.  smake is just plain
|> painful to try and figure out because it is so incompatible with
|> so many other makes.  All of the magic is more confusing than the
|> functionality that it provides...  In particular, why in the
|> world can't I do the following???
|> 
|> prog: ${OBJS}
|> 	list lformat="%s:%s" foobar:#?.o >obj.list
|> 	sc $(LDFLAGS) with obj.list pname=$@

Smake is included partly to ensure that everybody has at least a
basic-level make utility, and partly because there are some smake
customizations to make it work with the workbench - no other make
that I know of can take an icon as an argument when invoked from
workbench, plus smake can operate without a makefile on small
projects by invoking SC in a special way.

Diff is included because many people found it useful in version 5,
so rather than take it out of the product, we included it.  It doesn't
hurt the product to leave it in there.  I will admit we didn't work
on these tools much, in large part because of the very good PD tools
to do the same thing.  Our major effort was spent on those portions
of the product that can't easily be duplicated by a third party - the
compiler and optimizers, the debugger, the documentation.  (The editor
also got a fair bit of work because it needed it 8^).  However, 
somebody who doesn't have easy access to PD tools can use our tools 
and not have to go searching for somebody else's.

Anybody out there interested in modifying one of the PD make utilities
to run from the WorkBench?  If so, you could replace SMAKE entirely...

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.

Newsgroups: comp.sys.amiga.programmer