[comp.sys.amiga.programmer] SAS C 5.10A has problems

mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/20/91)

Not to start a new round of language wars, but I have been working
with SAS 'C' for a few weeks (yes, I still write lots of assembler, too :)

Anyway, I've found that SAS is full of bugs and problems, many of which I
can find workarounds.  At this point, I would like to get (perhaps) some
answers from anyone on the net who might have solutions.  E-Mail might
be preferable, but if you think there is value to others in the solutions,
please post.

Problem #1:
	BLINK complains about "extern struct Custom custom;"  It prints a
cryptic error message like "offset too far from A4".  I was able to fix
it by doing "extern struct Custom far custom;"  which may or may not be
preferable anyway (I say it is debatable :)  Many of the GfxMacros.h macros
rely on this custom variable.

Problem #2:
	When compiling some sources, I get CXERR: 99, which is NOT documented
in the manual.  Nice messages, eh folks?  Real descriptive :)  The compiler
does not complain about anything else in the source file.  This error comes up
during the Optimizing phase.

Problem #3:
	When compiling various sources, I get "Invalid section type in memory
option" error message.  I could find no documentation for this error message...

Unhappily working in C,
Mykes

:):):)

(hope that's enough smileys)

--
****************************************************
* I want games that look like Shadow of the Beast  *
* but play like Leisure Suit Larry.                *
****************************************************

231b3678@fergvax.unl.edu (Phil Dietz) (06/20/91)

In <mykes.3672@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:

>Problem #2:
>	When compiling some sources, I get CXERR: 99, which is NOT documented
>in the manual.  Nice messages, eh folks?  Real descriptive :)  The compiler
>does not complain about anything else in the source file.  This error comes up
>during the Optimizing phase.

SAS has a problem with static character strings and or string formats.
For instance, if I do an extended printf like
 
printf("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
       "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
       ...
       "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz");
 
It will crap out.   If I say  *string= "aaaaa....a"
                                       "bbbbb....b"
                                       ...
                                       "zzzzz....z"
 
it will crap out too.   I think the compiler has limitations on stuff
like this.  They REALLY need to update there error messages (even if they
are internal).
 
SOLUTION:
 
Start commenting out code and re-compiling seeing if it will give an error or
not.  This is the long annoting way, but it works.


---                    
   FACT:  the Nebraska Cornhuskers                           Phil Dietz 
          signed a contract to lose the        231b3678@fergvax.unl.edu       
          big games!  Yes, it's true!                 Univ. of Nebraska

mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (06/20/91)

In article <mykes.3672@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
   Problem #1:
	   BLINK complains about "extern struct Custom custom;"  It prints a
   cryptic error message like "offset too far from A4".  I was able to fix
   it by doing "extern struct Custom far custom;"  which may or may not be
   preferable anyway (I say it is debatable :)  Many of the GfxMacros.h macros
   rely on this custom variable.

You found and fixed the bug in your code. If you're building with the
small code model (the default), you've got to declare absolute
externals as "far".

   Problem #2:
	   When compiling some sources, I get CXERR: 99, which is NOT documented
   in the manual.

That's an internal compiler error, not an error in your code. There
are good reasons for it not being more descriptive (for instance, they
can't point at anything in your code and say that that caused the
error). You should contact SAS tech support.

   Problem #3:
	   When compiling various sources, I get "Invalid section type in memory
   option" error message.  I could find no documentation for this error message...


I haven't seen this one, but it looks like you're feeding the compiler
invalid options. If you post the code (and compiler options and
applicable SASCOPTS file), doing a better diagnosis might help. Then
again, if you're going to call SAS about #2, you might ask about this
on at that time.

SAS has the best technical support I've seen in any company large
enough to have a receptionist. You paid for it when you bought the
compiler; you should us it.

   Unhappily working in C,

I'm unhappy working in C, too - but not as unhappy as when I'm working
in assembler. However, I don't assume that every message from the
language translator that I can't figure out is a compiler bug.

	<mike
--
Must have walked those streets for hours,		Mike Meyer
In the dark and in the cold,				mwm@pa.dec.com
Before I really could accept,				decwrl!mwm
There's no place called hope road.

dillon@overload.Berkeley.CA.US (Matthew Dillon) (06/21/91)

In article <mykes.3672@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>
>Problem #1:
>	BLINK complains about "extern struct Custom custom;"  It prints a
>cryptic error message like "offset too far from A4".  I was able to fix
>it by doing "extern struct Custom far custom;"  which may or may not be
>preferable anyway (I say it is debatable :)  Many of the GfxMacros.h macros
>rely on this custom variable.

    This is not really a bug, but due to a feature in SAS/C -- the
    small-data model and resident support.  You HAVE to declare custom
    as far because it must be addressed with absolute addressing instead
    of A4 relative which only has +/- 32K range.

    I dunno about the other problems, but your solution to custom is
    correct.  Try compiling the other stuff with the large-data model,
    they could be related.

>****************************************************
>* I want games that look like Shadow of the Beast  *
>* but play like Leisure Suit Larry.		    *
>****************************************************

						-Matt

--

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA

nj@magnolia.Berkeley.EDU (Narciso Jaramillo) (06/21/91)

> When compiling various sources, I get "Invalid section type in memory
> option" error message.  I could find no documentation for this error message...

If you're using SASCOPTIONS (the Workbench interface to SAS/C), and
you've set it to generate precompiled header files, you may have run
into a bug where it generates the wrong option--"-h" instead of "-H".
I think it causes this "invalid section type" error when compiling.

nj

walker@twix.unx.sas.com (Doug Walker) (06/21/91)

Have you reported these problems to SAS/C technical support? 

I will summarize:

1. This is not a bug.  You are asking the compiler to
   use 16-bit offsets relative to an address register
   to access global data.  ("small data model")  You
   are attempting to refer to a data item that isn't
   accessible on this model - struct Custom is at a
   fixed location.  Therefore, you have to make an
   exception to the 'near data' rule - which you do
   with the 'far' keyword, exactly like you put it.
   If you really dislike 'far' for some reason, you
   can change the default with the -b0 option (You
   will have to link with different libraries.)

2. This is probably due to a known bug, although I
   can't tell without source code.  We elected not
   to fix it since the fix would probably generate
   other bugs and this one is relatively rare - this
   is about the fifth time anyone has reported it
   in the year that 5.10 and 5.10a have been out.
   Judicious use of the 'volatile' keyword is the
   workaround - contact tech support for details.

   BTW, the reason you get a CXERR 99 and not a
   more reasonable message is that CXERR's only
   come out when "impossible" situations

3. I don't know what this is, please contact tech
   support with additional details.  Is this the
   exact error message?  I've never seen it before.

In article <mykes.3672@amiga0.SF-Bay.ORG>, mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
|> Not to start a new round of language wars, but I have been working
|> with SAS 'C' for a few weeks (yes, I still write lots of assembler, too :)
|> 
|> Anyway, I've found that SAS is full of bugs and problems, many of which I
|> can find workarounds.  At this point, I would like to get (perhaps) some
|> answers from anyone on the net who might have solutions.  E-Mail might
|> be preferable, but if you think there is value to others in the solutions,
|> please post.
|> 
|> Problem #1:
|> 	BLINK complains about "extern struct Custom custom;"  It prints a
|> cryptic error message like "offset too far from A4".  I was able to fix
|> it by doing "extern struct Custom far custom;"  which may or may not be
|> preferable anyway (I say it is debatable :)  Many of the GfxMacros.h macros
|> rely on this custom variable.
|> 
|> Problem #2:
|> 	When compiling some sources, I get CXERR: 99, which is NOT documented
|> in the manual.  Nice messages, eh folks?  Real descriptive :)  The compiler
|> does not complain about anything else in the source file.  This error comes up
|> during the Optimizing phase.
|> 
|> Problem #3:
|> 	When compiling various sources, I get "Invalid section type in memory
|> option" error message.  I could find no documentation for this error message...
|>
--
  *****
=*|_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       plink: dwalker       bix: djwalker 

hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) (06/24/91)

In article <mykes.3672@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>Not to start a new round of language wars, but I have been working
>with SAS 'C' for a few weeks (yes, I still write lots of assembler, too :)
>
>Anyway, I've found that SAS is full of bugs and problems, many of which I
>can find workarounds.  At this point, I would like to get (perhaps) some
>answers from anyone on the net who might have solutions.  E-Mail might
>be preferable, but if you think there is value to others in the solutions,
>please post.

[...]

>Problem #2:
>	When compiling some sources, I get CXERR: 99, which is NOT documented
>in the manual.  Nice messages, eh folks?  Real descriptive :)  The compiler
>does not complain about anything else in the source file.  This error comes up
>during the Optimizing phase.

I've got this message, too.
The reason was a varargs function.
If you use varargs functions with the 'va_list' type, try two things:
First, declare the funktion as __stdargs and second, declare the 'va_list'
variable as 'volatile'.

E.g.:
void __stdargs Message(char *fmt, ...)
{
  volatile va_list list:
...
}


[...]
>
>Unhappily working in C,
>Mykes
>
>:):):)
>
>(hope that's enough smileys)


	Georg.
-- 
  hessmann@unipas.fmi.uni-passau.de		hessmann@unipas.uucp

mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/25/91)

In article <1991Jun24.110845.19273@forwiss.uni-passau.de> hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) writes:
>In article <mykes.3672@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:

>>Problem #2:
>>	When compiling some sources, I get CXERR: 99, which is NOT documented
>>in the manual.  Nice messages, eh folks?  Real descriptive :)  The compiler
>>does not complain about anything else in the source file.  This error comes up
>>during the Optimizing phase.
>
>I've got this message, too.
>The reason was a varargs function.
>If you use varargs functions with the 'va_list' type, try two things:
>First, declare the funktion as __stdargs and second, declare the 'va_list'
>variable as 'volatile'.
>
>E.g.:
>void __stdargs Message(char *fmt, ...)
>{
>  volatile va_list list:
>...
>}
>
>
>[...]
>>
>>Unhappily working in C,
>>Mykes
>>
>>:):):)
>>
>>(hope that's enough smileys)
>
>

Thanks for the help, but there are NO varargs usages in the source code.
The sources I am compiling is part of a port I'm doing.  The original
sources were Lattice from a few years back...

>	Georg.
>-- 
>  hessmann@unipas.fmi.uni-passau.de		hessmann@unipas.uucp

--
****************************************************
* I want games that look like Shadow of the Beast  *
* but play like Leisure Suit Larry.                *
****************************************************

sie@fulcrum.bt.co.uk (Sie) (06/25/91)

>>>>> On 24 Jun 91 11:08:45 GMT, hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) said:

 Georg> Nntp-Posting-Host: unipas.fmi.uni-passau.de

 Georg> In article <mykes.3672@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>Problem #2: 	When compiling some sources, I get CXERR: 99, which is
>NOT documented in the manual.  Nice messages, eh folks?  Real
>descriptive :) The compiler does not complain about anything else in
>the source file.  This error comes up during the Optimizing phase.

 Georg> I've got this message, too.  The reason was a varargs
 Georg> function.  If you use varargs functions with the 'va_list'
 Georg> type, try two things: First, declare the funktion as __stdargs
 Georg> and second, declare the 'va_list' variable as 'volatile'.

 Georg> E.g.: void __stdargs Message(char *fmt, ...)  { volatile
 Georg> va_list list: ...  }


This can't be the problem, I use varargs all the time and have not had
to do any of these things to make it compile ??

--
Simon J Raybould    (sie@fulcrum.bt.co.uk)            //              {o.o}
"Only joking ... Or am I ?" - Vic Reeves            \X/AMIGA           \-/
===========================================================================
Fulcrum communications L.T.D., Fordrough Lane, Birmingham, B9 5LD, ENGLAND.

hessmann@r2d2.fmi.uni-passau.de (Georg Hessmann) (06/27/91)

In article <SIE.91Jun25133827@spinach.fulcrum.bt.co.uk> sie@fulcrum.bt.co.uk (Sie) writes:
>
>>>>>> On 24 Jun 91 11:08:45 GMT, hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) said:
>
> Georg> Nntp-Posting-Host: unipas.fmi.uni-passau.de
>
> Georg> In article <mykes.3672@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>>Problem #2: 	When compiling some sources, I get CXERR: 99, which is
>>NOT documented in the manual.  Nice messages, eh folks?  Real
>>descriptive :) The compiler does not complain about anything else in
>>the source file.  This error comes up during the Optimizing phase.
>
> Georg> I've got this message, too.  The reason was a varargs
> Georg> function.  If you use varargs functions with the 'va_list'
> Georg> type, try two things: First, declare the funktion as __stdargs
> Georg> and second, declare the 'va_list' variable as 'volatile'.
>
> Georg> E.g.: void __stdargs Message(char *fmt, ...)  { volatile
> Georg> va_list list: ...  }
>
>
>This can't be the problem, I use varargs all the time and have not had
>to do any of these things to make it compile ??

Try this:
----tst.c-----
#include <stdio.h>
#include <stdarg.h>

char maxline[300];

void Message(char *fmt,...);
void Warning(char *fmt,...);

void Message(char *fmt,...)               /* issue a message */
{
  va_list argptr;
  char *ptr;

  va_start(argptr, fmt);
  vsprintf(maxline, fmt, argptr);
  va_end(argptr);
  ptr = &(maxline[0]);

  printf("%s\n",ptr);

}

void Warning(char *fmt,...)             /* issue a warning */
{
  va_list argptr;
     
  va_start(argptr, fmt);
  Message(fmt, va_arg(argptr, char *), va_arg(argptr, char *));
  va_end(argptr);
}
 
void main(int argc, char *argv[])
{
  Warning("TEST %d %s",2,"aa");
}
--------
Compile it with: lc -O tst

	Georg.

-- 
  hessmann@unipas.fmi.uni-passau.de		hessmann@unipas.uucp