Wayne A. King wrote:
Quote
As I previously stated: only in compilers which support it. The OP wants to
target 16-bit embedded systems. No 16-bit compiler I know of supports
long long or __int64.
BC5.02 isn't a 16bit compiler?
Quote
>See yourself. L is 64 bits for int formats, not 80.
Not in any 16-bit compiler which the OP is likely to use.
Including BC5.02 which the OP uses, and for which Lx is 64 bits?
Even in BC++3, %L(float) is 80bit, %L(int) is 64 bit. %X is an int
type. %LX isn't supported by 3.0, but it defines %L as 64 for int
types.
To claim that %LX is 80 is to claim that X is a float type.
Quote
Wrong again. The C compiler's parser can detect anything
which a Lint program can, and some do. According to your
Detecting and acting on that detection are two different things.
Quote
A float is 32 bits.
A bit specious as you've already posted that Boland always promotes
floats to doubles as printf arguments. One would presume that that
might not be "standard" behaviour.
Quote
long argument required (warning) <<-- line 13, 3rd arg
long argument required (warning) <<-- line 16, 2nd arg
Note that in both cases the message from the compiler says
"required", not "recommended". Note that the compiler implementors
"cared" enough to include the check(s) in the parser. Note that the
compiler "knew" that a mismatch was being attempted.
Note also that they didn't care so much as to make it an "error"
instead of a "warning". Big difference.
Quote
Note the effect on subsequent (left to right) arguments when an
incorrect type specifier is encountered. Are the displayed values
those which you expected?
Note that those effects are always to be expected when the sizes are
incorrect. The key to success is for the programmer to get the sizes
correct *for*his*compiler* as shifting platforms is pretty much
guaranteed to shift stack alignments. (16 bit progs push 16 bit
values, 32 bit progs push 32, probably 64 bit progs will push 64)
And different compilers might push floats instead of promoting to
double. And who knows what else some compiler writter might come up
with promotion wise. They might decide to promote all integer types to
128 bits so the RTL has it easy.
Quote
This compiler also flags %lf when used with printf, giving the message:
Meaning one presumes (since I don't have the docs for that compiler),
that that "feature" isn't supported by that compiler. Is there some
big lesson here? Compilers that don't support the features of your
"home" compiler, won't compile your code (properly). Does that mean
that we shouldn't use the new features? That seems to be your
argument. Won't be long now before we have int128 available natively.
Should we then limit ourselves to 64 bit because 128 isn't available
on all platforms?
Quote
error in format string (warning)
========================================================
Note the phrases "not syntactically correct" and "this will cause
unexpected behaviour at run time."
Also notice it is still a "Warning".
Quote
too many arguments for format string (warning)
Again note that it is the *source code* being parsed by the *compiler*,
something which you claim is never done. Note also the consequences
for ignoring some of these "warnings", as shown by the last example.
You are free to ignore syntax if you choose. You are also free to ignore
traffic lights and railway crossing barriers.
And, presumably, since the compiler only issued "Warning"s, it went
ahead and *compiled* the code "as written".
Quote
If %LX is used (suggesting a long long integer type) as in:
printf("%f\t%f\t%LX\n", 1.5, 1.5, 1.5); /* line 13 */
the compiler issues this message:
reptest.c(13) Warning: long long unsigned int format, double arg (arg 4)
It seems these compiler implementors also felt it worthwhile to
detect such mismatches when *parsing* the *source* code.
Yep, they "detected" it, but went ahead and *compiled* it as written,
no?
Quote
>If the compiler doesn't do what I tell it to do, then it is broken.
Not if what you tell it to do violates the rules of the language.
These don't violate any "rules" reguarding printf.
The rules of printf are very simple.
1) A string is passed.
2) Other variables my be passed if desired.
That's it.
The rest of the rules are on the compiler's side.
1) pass the string.
2) push any arguments on the stack.(How that is accomplished is
compiler dependant)
3) call the RTL
4) remove those arguments from the stack.
If it doesn't do those 4 steps, it's non conforming.
The RTL has it even simpler.
1) parse the string
2) Decode formats as the compiler docs contracted.
3) assume any parameters called for by the string are on the stack
Quote
>It can't decide on it's own that it knows what's good
>for the program(mer).
It does it all the time by optimizing code. e.g. - Omitting "dead'
code, using prefix operators when the programmer specified
post-fix (e.g. ++x instead of x++), merging strings, inlining or not
inlining contrary to the programmer's source code, unrolling
loops, using or not using registers when it decides to supply what
the programmer omitted or omit what he/she supplied, etc.
There you go, off topic again. Nothing to do with printf.
Quote
It can decide (quite rightly) to enforce the rules of the language,
You haven't shown it "enforcing" anything.
You have shown that some compilers complain more than others.
But all of those complaints not withstanding, it continued to compile
and run without dire results.
Quote
and to penalize programming anarchists who can't adapt. You
don't seem to have accepted the realities of programming with
And you don't seem to be able to accept the realities of real-world
programming, where you use what you've got, and cross-platform
portablitiy is just a pipe dream.
In an endevour where (what's the figure?) 80%? of all projects are
never completed or delivered. Where those that _are_ delivered are
never migrated (still plenty of people running mission critical DOS
apps) Where MS has a virtual monopoly on programs through their APIs
(can _any_ native Windows app be portable?) And where companies latch
onto a compiler vendor (hopefully Borland) and stick with them to the
bitter end ..... I think wasting effort making all those apps that
will never be "ported", "portable" from the beginning .. would be a
bad move to management's bottom line.
I still have clients on my DOS versions even though I ported to Win32
4 or 5 years ago and the update is free (16 to 32bit ASM wasn't all
that difficult a port, but the API shift was something else.) Platform
and retraining costs are factors for some users. (If it ain't broke,
keep what you've got)
Quote
anything other than a 1st-generation language.
Disregarding the rules of syntax and grammar in HLLs can have catastrophic effects.
No syntax or grammer rules broken or bent here. Syntax is way too
simple for that:
printf( char*, ... )
Quote
Granted C is more like a 2nd-GL than a 3rd, it nonetheless *does*
have requirements which are imposed on the programmer.
Yep, _most_ of the time. Just not here. With elipsis args, there are
no arg constraints. You can put whatever you want in there.
As you've shown, the compiler is also free to complain. Heck, there's
probably nothing to say it can't complain about perfectly legal and
standard and portable code too should the compiler be in such a mood.
As long as it goes ahead and *compiles* the code, it can complain all
it wants (about anything).
Quote
You're free to disregard them if you please, and accept the consequences.
Thankyouverymuch.
Quote
No "language police" will come knocking at midnight. (Unless I find
their phone number.) ;-)
As I've said before, I have no problem with you reminding us that
this or that is non-portable. That's fine. But insisting that a
person "can't" do something that they "can" just doesn't fly.
That a compiler generates a "warning" doesn't signify "can't".
When a compiler means "can't", it says "Error" and refuses to compile.
If it compiles, then it "can". (Might not do what you think, but
that's what programming on the edge is all about.) ;->
