C questions
10 messages in this thread
I have 3 questions here, two which directly concern the SAS/C environment
and one which is aimed at the (I believe) Commodore header files…
Firstly, does anyone know why <clib/alib_protos.h> includes
<libraries/mathffp.h>? Removing it doesn't seem to affect anything, and
having it in there wreaks havoc with code using the ANSI math.h and the
default SAS/C floating point math. (In particular, trig functions are
redefined as something else, causing prototype problems and worse…)
Second, does anyone know why oml produces library too large errors
whenever I try to put together a library with lots of debug (compiled with
the -d5 option) information in the modules? I'm finding it difficult to
build my library without reducing the debug info, and I *want* that debug
info there for CodeProbe.
Finally, I just saw an ad for SAS/C 6.0. Anyone have any info on that?
–>Steve Bennett
1) Clib/alib_protos.h is produced by C=. Since they want you to be able to
do math operations as well, my guess is that it seemed the logical place to
include it. Problems related to SAS/C with this are due to the fact that
SAS/C does not encourage you to use the AmigaLib I/O and Math functions.
2) That is a bug in OML. There is no workaround, you must manually JOIN
the object modules together to form a library.
3) There was a recent upload by SAS which describes what was in 6.0. A
message was recently posted on another service that it was delayed due to
some sort of production problem.
Note: I have no association with SAS Institute.
The alib_protos problem is annoying in and of itself. A prototype
file has no business including any header unless that header is
absolutely required to allow the prototype file to compile properly.
If I want to use MathFFP functions directly, I'll include the header
myself, thank you. I think this one deserves a note sent off to CATS.
Thanks for the information about oml, though. I had no idea one could use
JOIN to form a library.
–>Steve Bennett
SAS doesn't encourage the use of the Commodore functions because
they don't come close to adherance to the ANSI standard or any
other standard.
OML has a size limit of, I think, 256k per library. This is not
a bug, but a design flaw which is fixed in 6.0.
Version 6 will begin shipping September 14, unless you count the
World of Commodore show in Pasadena September 11-13 (we will be
there.)
–Doug
Doug,
I ordered the upgrade from SAS Book Sales, and received a letter stating
that it was on backorder. Would it be possible for me to arrange to pickup
my upgrade at WoCA and save a few days shipping time?
-Homer
Flying on Auto
No, sorry – our marketing people have said that we can't
sell upgrades at the show, only new product. It would
make things more complex than we would have time to deal
with there in the booth.
–Doug
Steve,
I don't know the answer to any of your questions but do have a question of
my own — why -d5 ? Isn't that a bit of overkill? I've got a program
that's 240k executable — when compiled with -d3 (which takes near forever
to do) it results in a 5M+ file — I'm sure -D5 would be even worse in
both time and size and I'm not sure it really gives you much more as for
debugging info.
-sja
Why -d5? Good question. Since I am using CodeProbe, I naturally
wanted as much debugging information as I could get in there. But
perhaps I really don't need that much. What's the minimum level of
debugging info one can get away with and still use CodeProbe
effectively? (My main program is over 1.1M with -d5, and strips
down to just over 50K when I "blink p TO p2 NODEBUG"…)
.–>Steve Bennett
Steve,
I think you'll find -d2 or -d3 very effective.
Basically, -d3 does everything you need. -d3 only writes
information for symbols that you actually use; -d5 writes
information for all symbols.
A good strategy is to compile everything with -d1, then
when you need to work on one specific module, use a higher
debug level.
–Doug