Subj : Re: Any help on why? To : borland.public.cpp.borlandcpp From : waking Date : Thu Jul 08 2004 07:29 am On Wed, 07 Jul 2004 12:58:52 -0700, Bob Gonder wrote: >My docs (BCB) show LX as uint64. So don't know about "intended". BCB is not topical in this particular newsgroup. It's what happens with BC++ compilers up to 5.02 that's germane. As I recall, the OP is targeting 16-bit embedded systems and no Borland DOS compiler supports the extended integer types. I believe L can be used legitimately with integer type long long in compilers which support it. However, that type is a later addition/extension to the language(s) - as is __int64 - and was not in the C90 language spec which is what all compilers topical here were written to conform to. Further, while 5.02 supports __int64 as a language extension (5.02 was released primarily for compatibility issues with the then-new Builder version 1) such types are not supported in the 16-bit compiler which came with 5.02, only in the 32-bit compiler. >Also firmly disagree on "integer types only". You can use %X on >ANYTHING that goes on the stack, and has the matching size for the >prefix to X. I can't see Any way for that to mess up. If the syntax defies the language spec, the compiler writer may do ANYTHING with it when parsing the source code. This includes ignoring one or the other of the type specifier(s) or arguments. In the case of %LX, if not specifically supported as an implementation-specific language extension, the implementation *may* ignore the L altogether if it's not appropriate, or apply it in unknown or unpredictable ways. Again, you're trying to guess what the compiler implementors are *always* going to do. If %X applied to a non-integer type is not specifically supported by the language spec or by a compiler extension, the implementor may freely and arbitrarily choose to ignore that arg altogether. It's dealer's choice. >Then they shouldn't have placed 'cast' and 'union' in the language. >They encourage bit-fiddling. Which is why many C/C++ language gurus deprecate their use, as they do bitfields. (Note that bitfield processing changed in 5.02 from earlier versions. leading to extensive debate here as to whether or not their handling should be considered "broken" in 5.02.) >It's dificult to write operating systems in C without bit fiddling. The OP is just starting to learn the language. I doubt that he will be writing an OS using C any time soon. ;-) The rationale behind going to C (and other higher level languages such as PLUS - Programming Language for Univac/Unisys Systems) when writing OSes was precisely to make the OS code portable across vendor's hardware offerings. The more bit ops incorporated, the more portability suffers. >Results are what count in >those cases, and wasting time making pretty (truly byte-fiddling) >expansive code just to see what's going on in there, especially when >that code is probably going to be deleted after the bug is caught..... Not sure if that sentence parses correctly. ;-) Are you arguing in favour of wasting time (such as trying to force the C language to do things it wasn't designed for), or against it (such as using non-implementation specific methods)? >For production code, I use byte-fiddling routines (my asm heritage >makes me prefer not to use the printf family, and since I don't use >floats, it's no big loss to convert for myself). You're an anachronism. ;-)) >Depends I guess, on if you want to use it "as designed" in the 60/70's >or "as designed" in the 90's. As designed according to the C90 spec here and elsewhere, until Borland releases a C compiler which supports the C99 spec. Of course, one is free to use documented and officially supported features which are an extension to the language. But even there, trying to use such features in a way which deviates from their intended functionality is usually ill-advised. >I still don't think of C as "designed" in that manner. What do you think the ANSI Standard for the C language was written for, if not as a design specification? Incidentally, most compilers give sparse diagnostics. Using a more sophisticated and robust syntax checker such as Lint will often flag attempts to mismatch specifiers and arguments in printf/scanf function calls. For example, here is what the shareware CLint++ utility says when fed %X and %LX with type double args: ======================================================= Warning mantissa.c(15): printf: %X requires integral argument (arg 2) in function main printf: % requires integral argument printf() and its companion functions (sprintf() and fprintf()) can be one of the most prolific sources of problems, mainly due to using incorrect '%' conversions. Supply an integral argument, or change the conversion. You only get this warning if you enable Options | Lint Options | General | Check printf-like function calls (or -wprn for the command line program). Warning xresult.c(50): printf: %LX requires 'long long' argument (arg 3) in function AddDouble printf: %L requires 'long long' argument printf() and its companion functions (sprintf() and fprintf()) can be one of the most prolific sources of problems, mainly due to using incorrect '%' conversions. Either remove the 'L' specifier, or change the argument type. You only get this warning if you enable Options | Lint Options | General | Check printf-like function calls (or -wprn for the command line program). ======================================================= -- Wayne A. King (waking@idirect.com, Wayne_A_King@compuserve.com) .