Simple C question
28 messages in this thread
A #pragma is something that is unique to the compiler system you're using.
So how does a pragma differ from a bug or a feature? 🙂
A feature is a bug people have found a use for. 🙂
// .Cruising on AutoPilot
\X/
I remember an early GNU C compiler that invoked "rogue" whenever it encountered
ANY pragma. 🙂
Hey, that's legal, according to the ANSI standard!
#pragma is, in my opinion, a misfeature of the standard because
there is no regulation or registration of pragmas. Any other
solution would have been ugly and disgusting, too, however,
so we run with what we've got.
Basically, the #pragma statement allows the vendor to claim full
ANSI compliance but still include machine-dependant things –
two inherently contradictory goals, but both necessary/valuable.
–Doug
Borland C++ for Windows has a way to simply use its command-line switches
within a pragma, I believe… You're right, some sort of registry would be
very helpful. What, you didn't like Pascal's approach, with structured comments
like {$S=5} ?
>some sort of registry would be very helpful
Although that makes sense in theory, the issue is that a pragma is doing
something implementation defined. I agree it might be nice to have some of
the common ones like oh structure packing make consistent, but my guess is
that enough of them wouldn't turn out consistent anyway and hence not be as
useful and back to the current situation.
By a #pragma registry, I just meant that the token immediately following
the word "pragma" would be registered and guaranteed unique among all
vendors.
I.E. if you want to use a SAS/C pragma, you do
#pragma sasc ….
if you want to do a Borland C++ pragma, you do
#pragma borlandc …
or whatever. Sure, what the #pragma DOES is implementation-specific.
The current definition allows two different vendors to define pragmas
with identical syntax but different semantics. If there was a
registered name there, at least the compiler would know which ones
to ignore.
–Doug
>Hey, that's legal, according to the ANSI standard!
Legal: yes. Conforming: depends.
>#pragma is, in my opinion, a misfeature of the standard because
>there is no regulation or registration of pragmas. Any other
>solution would have been ugly and disgusting, too, however,
>so we run with what we've got.
Right. It would be nice to get something more solid, but there isn't really
much more than can be done.
>Basically, the #pragma statement allows the vendor to claim full
>ANSI compliance but still include machine-dependant things –
>two inherently contradictory goals, but both necessary/valuable.
Right, but not necessarily at the same time. Anyway, yes,
both are indeed necessary and valuable. Of course the "evil" is that the
standard is written with the intent of "general purpose" language, and that
isn't good enough some times on specific platforms. Of course the liberty
that #pragma provides goes beyond that too.
John,
Pragmas are a 'defined' way to add "features" which are then further
defined to be implementation specific. Actually, it's sort of the kind of
thing you'd expect from a committee on C
> Pragmas are a 'defined' way to add "features" which are then further
>defined to be implementation specific.
Yes. And an oft oversight is that even though #pragma is a preprocessor
directive it does not just control things at that stage. It is a message to
*any* part of the compiler system that the vendor chooses.
>Actually, it's sort of the kind of thing you'd expect from a committee on C
Well, it was brought into the language formally by the ANSI C committee.
Wouldn't you agree that it is a necessary evil though?
Yes,#pragmas, as mystical as they may seem (to me) provide a standard way to be
non-standard! Specifically addressing the proto pragmas for SAS, somewhere in
the docs it does mention that the pragmas know the args for all these amiga
library f'ns, and generate more efficient inline-assembly type calls to these
routines… which makes me wonder why the protos aren't all like this.. like
having a compiler option to generate lame code on purpose… that defaults to
ON.
To include this information on the prototypes would require a significant
rewrite of the syntax for prototypes, and it would also require
Commodore to provide their prototypes with the changes already
added. Since such prototypes would not prove usable on C compilers
that did not implement the syntax, the decision was made to keep
the information in #pragmas instead.
If you include the SAS/C provided header files in <proto/…> directly,
you DO get the #pragmas as well as the prototypes. Originally, Lattice
generated and provided the prototypes and #pragmas that came with its
package; the current <clib/…> and <pragma/…> directories came about
later as Commodore started providing them, but our <proto/…> directory
is still good.
If we don't see a #pragma, we don't know the information, and we can't
generate inline code. I don't see how this is a feature that is "off by
default". In fact, it's pretty easy to use – just one #include and
everything else is automatic.
–Doug
Doug,
>significant rewrite of the syntax for prototypes….."
Lesse, let's replace the '__asm' with '__asmlibrary <librarybasename>
offset' and let's further make the offsets positive, and start with 0 and
count by one, instead of this silly hexadecimal and count by 6 stuff.
The argument against changing the prototypes bacuse they wouldn't work on
all compilers won't wash. The pragmas don't work on all compilers.
As for the 'option being off or on' I think what Arnie is saying is that
there is a lovely (and probably MORE important feature) called prototypes
which only do 1/2 the job. The error checking is there, but the code is
poor, you _need_ to add both includes.
Yes, we have rewritten the syntax for prototypes if you use the
__asm stuff; however, Commodore was providing prototypes for
us that we were not allowed to modify. They didn't want to
add special stuff for us because it wouldn't compile under
other C compilers. So we end up with what we have.
–Doug
This thread inspired me to fix all my current code to do the right thing… the
only problem seems to be with clib/stdio and stdio… which goes away when I
bag the <stdio.h>
or the clib/stdio thing.. in all I ma VERY happy with the system.
Make sure you are linking with the correct libraries…
if you #include <clib/stdio.h> then you MUST link with amiga.lib
before sc.lib, and you must be aware that the stdio you are using
is non-ANSI.
If you include <stdio.h>, then you MUST link with sc.lib before
amiga.lib.
–Doug
>which makes me wonder why the protos aren't all like this.. like
>having a compiler option to generate lame code on purpose… that defaults to
>ON.
I'm not sure I understand. Do you mean have the information in the
prototypes, or have a #pragma for every single function possible?
Please note that inlining functions *is not* a cure all activity that should
take place, even with some small routines. Lame is in the eye of the
beholder.
Greg,
Arnie was refering to the system calls, and 'lame' is a good word for
it. I always thought it amusing that the compiler puts all the args on
the stack so the 'glue' routine can put them in registers so the system
can put them back on the stack.
yeah, I'm a bit defensive, cause I'm working with assembly guys, and when they
look at the disassembly they laugh at me… then I ask how many lines in
theri equivalent of printf and ask if they could easily do octal also… and
they shut up abit.
Arnie,
If those assembly guys are laughing at your code, #include the
right #pragmas and let them have another go.
–Doug
I've switched over to those pragma includes, but I'll have to get into trouble
before we get into group dissambly mode again.. should be about 2 days ! ;->
Arnie,
Also make sure you use PARMS=REGISTER (and run the optimizers, of
course.) You'll need prototypes for all your own functions to use
PARMS=REGISTER.
I assume that you're already using NOSTACKCHECK.
–Doug
Doug,
I presume that pragmas are a very compiler-personal thing. Is it possible to
predict what would happen if you had a program with SAS/C pragmas in, but
passed it through someone elses preprocessor, such as DICE, before compiling
with SAS. Would the pragmas get through unscathed, or is it a try-it-and-see
unpredictable thing?
Steve the G. [BEDFORDSHIRE, UK]
Steve,
Not sure. Since #pragmas are a preprocessor thing, probably the
other preprocessor would swallow it – but then again, maybe not.
The ANSI standard requires compliant compilers to at least ignore
#pragmas that it doesn't recognize. Unfortunately, there is no
way to tell if a compiler THINKS it recognizes something, but
really doesn't. I.E. if your compiler has a #pragma foo, and you
compile with another compiler that also has a #pragma foo that
does something totally different, you can get bollixed up bigtime.
For the most part, however, this isn't too much of a problem.
Such collisions are relatively rare. I don't know if DICE would
pass the #pragmas through, but it probably wouldn't choke on them
either.
–Doug
I take it by 'ignore' you mean "print a warning" is OK. If you don't, I'd
like to report a bug in 6.2:
#pragma once
causes a warning to be emitted by the compiler.
…btw, it seems to be a nifty thing that one of the Mac compiler uses
which says "do NOT include me twice". Much cleverer than the old:
#iffdef WIDGET_INCLUDE
#define WIDGET_INCLUDE
…
..the rest of the include file
…
#endif
Try it with the ANSI option on 8^) That's one of the few warnings
that is actually *suppressed* by the ANSI option, because the
standard says that we have to accept it without a "diagnostic".
We could of course classify that particular warning as "not a
diagnostic", but that would complicate matters.
–Doug
>necessary evil…
Something is neccessary; I'm not sure it's pragmas.
let's look at the ones for SAS as an example:
the …call pragmas could be MUCH better handled (in my opinion) by some
sort of 'modification' to the __asm prototyping. I'm absotively
clueless why this didn't occur to the ANSI committee (or maybe no one
there had ever worked on a machine with DLLs??)
the msg pragma….yes it's useful to turn on and off errors and warnings.
As a matter of fact it's SO useful, it should have been standardized.