Subj : Re: Any help on why? To : borland.public.cpp.borlandcpp From : Bob Gonder Date : Sun Jul 11 2004 07:01 pm Wayne A. King wrote: >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? >>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. >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. > 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. >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. >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. >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? >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". >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". >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? >>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 >>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. >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. >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) >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*, ... ) >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). > You're free to disregard them if you please, and accept the consequences. Thankyouverymuch. >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.) ;-> .