It was thus said that the Great ben via cctalk once stated: What CPUs did it correctly? And how did they handle signed vs. unsigned promotion? unsigned char *ufoo; unsigned long ubar; ufoobar = *ufoo + ubar; signed char *foo; signed long bar; foobar = *foo + bar; -spc

When signed and unsigned values (variables or literals) of the same size are combined the compiler assumes that all of the values are signed.  This can yield a problem if the unsigned integer is large enough that the most significant bit is set because this bit indicates sign. for example: uint8_t bValue = 128; int8_t   bValue1 = -128 Both have the same value in memory (0x80). On 8/15/2024 3:52 PM, Paul Koning via cctalk wrote:

More likely the language designers, assuming the compiler doesn't have a standards violation in its code. In the case of C, the type promotion rules that were just explained are rather bizarre and surprising. Other languages do it differently, with perhaps fewer surprises. Some define it very carefully (ALGOL 68 comes to mind), some not so much. paul

Fred, That is true, Order of expression is undefined between execution points that is why the following statement can produce different results on different compilers: A = 1; F = A++ * A++; Without the use of parenthesis the is no way for the user to know beforehand what the value of F will be.  The only guarantee is that when the before the next instruction is executed the all postfix operators will be evaluated prior to the start of the next C statement. As a general rule rvalue expressions are calculated by the pre-compiler and not the compiler.  So the line: ulDays  = ulSeconds / ( 60 * 60 * 24 ); Would be converted by the precompiler to: ulDay = ulSeconds / 86400; The calculation of the lvalue ulSeconds / 86400 will be handled at run time. However, if ulSeconds is defined as a const it is possible that a smart precompiler will do the entire calculation and only the assignment will be done at runtime. It is possible that the volatile keyword might cause the order of expression to be altered. uint32_t * volatile ulpDMAAddress = 0xffff0000;  // Note this is a volatile pointer and NOT a pointer to volatile data. uint32_t *ulpMyPointer; ulpMyPointer = *ulpDMAAddress++ + *ulpDMAAddress++; My mind is getting numb just looking at that code.  Suffice it to say that using multiple prefix/postfix operations in a single execution point is heavily deprecated because the actual results are implementation defined and my even be different depending upon what other math surrounds it. Another implementation specific feature of C is the order of bits in bit fields.  They can be assigned from most significant to least significant or vice-versa.  It is totally up to the compiler. As Allan Holub says C and  C++, in his book of the same name, gives the programmer "Enough Rope To Shoot Yourself in the Foot" On 8/15/2024 6:45 PM, Fred Cisin via cctalk wrote:

When I was teaching C, it was sometimes quite difficult to help students who had firm assumptions about things that you can'r assume. Such as the sequence of operations in the multiple iterations examples that we both used. I tried desperately to get them to do extensive commnets, and use typecasts even when they could have been left out.

On Thu, 15 Aug 2024, Mike Katz wrote: Advanced programming techniques don't help until they can actually successfully think about the problem. I had a guy working for me VERY briefly, with a UC Berkeley degree, but he couldn't figure out how to do 3-up mailing labels on a daisy wheel printer! (sequence not mattering becuse they were manually peele off and use for a mailing.) He couldn't figure out any way to do it other than needing a way to roll the paper back to get back to the top for the next column! not on THAT printer! (simple way - read three records into memory, print them side by side, and then advance the paper) He had a few other similar shortcomings. I let him stay around until he peeled and stuck all of the labels, and to give him time to find another job. I gave a final exam question on how to sort/sequence the records of a large file that was too big to fit into memory. Several students who had gotten their start at the university insisted that the only way it could be done was to add more memory. (simple way - read a memory sized block from the file and sort it; do that again, until you have a whole bunch of sorted shorter files, do a merge sort of those) Another: "A client has a large file that is in order. But each day/week/month, additional records are appended to it. What's the best sort algorithm to get the file back into order?" (simple 1: put the new records into a separate file, sort that; then do a merge sort between that and the main file. simple 2: (if it isn't too large to manage) a bubble sort, with each pass starting at the ENF of the file where the new records are, and working towards th beginning, or a "shaker sort" that alternates direction. The maximum nuber of passes is the number of records that were out of order. (a "shaker sort" is the best sort algorithm for taking advantage of any existing order, such as a few random records being in the wrong place) -- Grumpy Ol' Fred cisin(a)xenosoft.com

That is the reason for the stdint.h file.  Where you specify the width of the variable in bits int8_t, int16_t, uint16_t. etc. On 8/15/2024 8:39 PM, ben via cctalk wrote:

Ben, The purpose of the stdint.h file is to allow the programmer ti specify the size of the variables. On some systems is an int 32 bits or 64 bits (or even 16 bits on older systems or 16 bit micros).  The size of an int is not specifically defined in the C standard. Especially when doing embedded coding the size of a variable (or the size of the data pointed to by a pointer) is very important. The stdint.h file is created by the authors of the compiler so that the programmer can specify the size of the variable that he wants. /int A/ may or may not be 32 bits but /int32_t A/ will always be 32 bits. This is mostly not a problem on modern 32 bit microprocessors where an int is 32 bits  and a short is 16 bits. However, on that system is a long 32 bits or 64 bits?  By having the typedefs in the stdint.h file, the programmer can specify the exact size of the variable. On 8/16/2024 1:38 AM, ben wrote:

On Thu, 15 Aug 2024, Mike Katz wrote: I will readily concede that ANSI C has fewer problems with ambiguous code than the K&R C that I learned. But, for example, in: X = foo() + bar(); has it been defined which order the functions of foo() and bar() are evaluated? Consider the possibility that either or both alter variable that the other function also uses. (Stupidly simpe example, one function increments a variable, and the other one doubles it) As another example of code that I would avoid, int x=1,y=1; x = x++ + x++; y = ++y + ++Y; give 2, 3, 4, or 5? is heavily dependent on exactly when the increments get done. But, thorough careful typecasting, use of intermediate variables, etc. can eliminate all such problems. 'course "optimizing compilers" can (but shouldn't) alter your code. If you don't explicitly specify exactly what you want, "C gives you enough rope to shoot yourself in the foot" (as Holub titled one of his books) But, I've always loved how easily C will get out of the way when you want to get closer to the hardware. -- Grumpy Ol' Fred cisin(a)xenosoft.com

On 8/15/2024 3:41 PM, Sean Conner via cctalk wrote:

I'm pretty certain you are wrong about the byte case below. The C standard says something about no math will be done smaller than a short. I don't have it handy so can't quote exactly. But what that means is before the two bytes are added, they are promoted to short / uint16_t and then added. ... In this program segment: uint8_t a = 255; uint8_t b = 255; uint16_t c = 0; c = a + b; printf("c: %d \n", c); it will print 510 instead of the 254 that would result if it were added as bytes. Will Grownups never understand anything by themselves and it is tiresome for children to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince

On Thu, Aug 15, 2024 at 01:41:20PM -0600, ben via cctalk wrote: [...] This makes them a perfect match for a brain-dead language. But what does it even *mean* to "automaticaly promote smaller data types to larger ones"? That's a rhetorical question, because your answer will probably disagree with what the C standard actually says :) Widening of integers is normally done through left-extending the sign bit. For unsigned values, the sign bit is implicitly zero although we usually say "sign extend" or "zero extend" to be clearer about whether we're dealing with signed or unsigned values. C will typically do one or the other of these, but not always the one you expected. For sign-extension, m68k has the EXT instruction, and x86 has CBW/CWDE. For zero-extension, pre-clear the register before loading a smaller value into a subregister. From the 386 onwards, there are MOVZX/MOVSX which do load-and-extend in a single operation. If the result of a calculation is then truncated when written back to memory, then the upper bits of the register may have never had an effect on the result and did not need to be set to a known value, so this palaver is quite unnecessary. The thing was only extended in the first place because C's promotion rules required it to be, and the compiler backend has had to prove otherwise to eliminate it again. As it happens, it's not unnessary on modern out-of-order CPUs, so there's a lot more use of MOVZX etc on code compiled for x86-64. Loading into a subregister without clearing the full register first introduces a false dependency on the old value of the upper bits, resulting in a pipeline stall and performance hit. However, this is "just" for performance rather than correctness. Said performance hit is likely the main reason why x86-64 automatically zero-extends when loading a 32-bit value into a register, and so MOVZX is no longer required for that operation. So in fact x86 *does* "automaticaly promote smaller data types to larger ones". Not doing so would cause an unacceptable performance hit when running 32-bit code (which was basically all of it back in 2003 when the first Opteron was released) or 64-bit code making heavy use of 32-bit data. Now, what kind of badly-written code and/or braindead programming language would go out of its way to be inefficient and use 32-bit arithmetic instead of the native register width? I'm sure you can "C" where I'm going here. `int` is extremely special to it. C really wants to do everything with 32-bit values. Smaller values are widened, larger values are very grudgingly tolerated. C programmers habitually use `int` as array indices rather than `size_t`, particularly in `for` loops. Apparently everything is *still* a VAX. So on 64-bit platforms, the index needs to be widened before adding to the pointer, and there's so much terrible C code out there -- as if there is any other kind -- that the CPUs need hardware mitigations to defend against it. It's not just modern hardware which is a poor fit for C: classic hardware is too. Because of a lot of architectural assumptions in the C model, it is hard to generate efficient code for the 6502 or Z80, for example. But please, feel free to tell me how C is just fine and it's the CPUs which are at fault, even those which are heavily-optimised to run typical C code.