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