supercat

@another-dave It's a shame the Committee wasn't willing to recognize certain traits that implementations should share whenever practical, and also recognize that because C's purpose is to accomplish tasks that FORTRAN can't do well if at all, it shouldn't try to compete with FORTRAN on the tasks FORTRAN does best.

In a ones'-complement system with 18-bit int and 9-bit char, for example, using 9-bit arithmetic to multiply 171 by 3 would yield 2, but using 18-bit arithmetic and truncating the result to 9 bits would yield 1. On a two's-complement system both calculations would yield 1.

@dave: Did those mahcines have integer types that were larger or smaller than a byte? Concepts of integer promotion and truncation really only make sense on a platform where the radix of smaller types divides easily into the radix of larger ones--something which is true in two's-complement but not ones'-complement.

@Lundin: I think the fundamental root problem is that there has never been a consensus on the committee as to whether C is a low-level language or a FORTRAN replacement. FORTRAN never characterized non-erroneous actions as UB, but the C Standard uses that phrase as a catch-all including constructs whose behavior will be defined if and only if the programmer has information which could not be learned by any language-recognized means, but might be learned via means outside the language (e.g. execution environment documentation).

@Lundin: The problem is that there are a few situations where precise wrapping semantics are more expensive than looser semantics would be, but clang and gcc optimizers use an abstraction model where everything must be either rigidly defined behavior or anything-can-happen UB.

@JonCuster: More to the point, C89 was never intended to have a notion of "defined to be undefined", but merely cases where it waived jurisdiction.

@user71659: If users aren't allowed to set non-empty passwords, and admins don't set non-empty passwords, how would any come into existence?

@user71659: If the only password-free accounts that are allowed to exist are public access accounts, what's the harm in people being able to probe for them?

I wonder why panel GFCIs aren't considered a strongly recommended safety improvement for three-wire stove receptacles, in scenarios where running a proper ground would be difficult? While a grounding conductor does improve the safety of even GFCI-protected devices, going from nothing to a GFCI is still a huge safety improvement.

@KenShirriff: I wonder if it would have made sense to perform all of the character-to-pixel translations for each character simultaneously, and use delay lines to delay all but the first row, and then multiplex the character generation for multiple terminals, since each terminal would only need one scan line out of every 6 or so.

Are you talking about CRTs which are directly controlled by computers, or would CRTs in things like terminals also count?

...to find and fix all of the misplaced cards identified by the program. Having records go past the 80-byte barrier would add a lot of additional complexity to database management procedures, since one would need to somehow ensure that all of the cards associated with each record were kept together.

A lot of people really don't appreciate that there would be a qualitative difference between records that fit in 80 characters, and those that don't. If records fit in 80 characters, adding a record to a database merely requires punching a card and inserting it into the stack at the proper place. Removing a record would generally simply require removing a card. If one or more cards might have been inserted in the wrong place, one could either use a deck sorter or a program which would list every pair of cards that wasn't in sequence, allowing someone with a mostly-sorted deck...

...targeting "large" CPUs. The use of C as an application language should be limited to platforms where passing pointers to array segments is usefully more efficient than managing array bases and indices separately.

@CPlus C was designed in an era where passing a pointer to the start of an array segment was cheaper than passing an array's base address and the segment's starting index, but modern "large" CPU architectures have reduced the cost of separating base+index, while the benefits compilers could reap by assuming that all references to a given piece of storage will use a common base have increased. Fortran-style languages could be faster and safer than C-style languages when...

Really, the loading code should have been written in somehting other than Low Level C, so the quesiton of performance costs of supporting low-level C should be irrelevant, but regarless, I think it fit my overall point which is that most programs spend most of their time in loops which comprise only a tiny fraction of their overall code, limiting the value that could be reaped by trying to optimize everything else.

...but the Standard doesn't promise that sscanf won't examine storage between the last (non-zero) byte that's actually used and the next zero byte, and the Standard Library sscanf version used by GTA V would always start by performing strlen on the passed string.

@CPlus I mention sscanf, btw, because the game Grand Theft Auto would sometimes take much longer than normal--by about a minute IIRC, to load a mission or save file, and the problem was--after many years of player frustration, found to be a result of code which used sscanf to parse something at the start of a buffer which wasn't always zero terminated. Some versions of sscanf won't care about any parts of the buffer beyond what's actually used...

...of a billion would yield less than a 1% overall performance improvement. Modifying a sscanf implementation so it doesn't precompute the length of the string being scanned, by contrast, might slash load times drastically.

@CPlus Even if one ranks portions of the code based on the maximum fraction of any one contiguous second of execution time that would be spent therein, for many executions of many programs the median value would be zero, and for many more programs the median value would never get very big. If every call to foo would result in the system spending 1 microseconds processing code within foo, and 100 microseconds processing code within bar, speeding up the code within foo by a factor...

...for compilers to reap maximum benefits from programs that can benefit from the optimizations, while at the same time making it easier for programmers to write code that works by specification, rather than as a consequence of "missed optimizations".

For the extremely vast majority of programs and potential optimizations the Standard tries to use tricky rules to allow, it would be easy to identify at least one of the following as being true: (1) the optimization could be applied broadly without adversely affecting the program, or (2) performance objectives could be satisfied without trying to apply that particular optimization at all. Specifying a means by which programmers can say which situation applies would make it easier...

@AlexisKing The issues raised by such defect reports would evaporate if the Commitee would recognize that if for 90% of tasksthe most efficient way of accomplishing what needs to be done wouldn't involve doing X, allowing compilers to assume that programs won't do X might improve the performance of 90% of tasks, but woudl be at best counterproductive for the remaining 10%.

A fundamental difference between the FORTRAN abstraction model and Dennis Ritchie's abstraction model is that in the FORTRAN abstraction model, a compiler is entitled to assume that programmers won't exploit any knowledge about programmers' inner workings beyond what the Standard would provide, while C was designed around the assumption that programmers would often know things about the execution environment that a compiler likely wouldn't know and in many cases couldn't know.

...would have no choice but to behave in a manner whose observable behavior as defined by the platform ABI would be consistent with performing the indicated sequence of steps. Note that in most cases, platform ABIs would give compilers a lot of flexibility with regard to how they process things, thus allowing efficient C code to be translated into efficient machine code.

Writing a langauge spec that would satisfy the needs of the extremely vast majority of code written for freestanding implementations (nearly all such code that doesn't use nonstandard toolset-specific syntax) would not be difficult. Recognize the notion of a platform ABI that defines a few operations, and then specify that a translator's job is to convert each function into some kind of build artifact such that an execution environment that satisfies all of a compiler's documented requirements

...the output from that latch will be fed to a color-generation circuit when raster scanning is within neither the main displayable area nor a blanking interval.

...to whether or how the execution environment specifies the consequences of the behavior. If a Commodore 64 is used to run code generated by a low-level C implementation targeting the 6502 and given (char volatile*)0xD020 = 7;, the screen border should turn yellow, regardless of whether the author of the C implementation knows anything about Commodore 64, screens, borders, or the color yellow, because the Commodore 64 hardware has a 4-bit latch which is triggered by writes to 0xD020, and...

...which would otherwise specify the behavior". Many implementations, even with optimizations disabled, may in some corner cases slightly deviate from the behaivors that might be implied by that rule, but a prerequisite for allowing programs to work by specification is recognizing the existence of a dialect which specifies many actions' behavior as "Instruct the execution environment to do X, with whatever consequences result", without regard...

A lot of software, including most software that runs on embedded platforms, is written in a form of high-level assembly language invented by Dennis Ritchie, which many compilers can be configured to process, at least with optimizations disabled, which augments the Standard with "Any parts of the Standard which would characterize an action as invoking UB are subservient to parts of the Standard, K&R2, and the documentation for the implementation and execution environment...

@AlexisKing To put things another way, if an equality test between a "just past" pointer and a pointer to the following object were UB, then the clang/gcc behavior would be correct. I can think of no other abstraction model that would fit the design behavior of clang and gcc.

@AlexisKing The presence of the equality comparison effecitvely corrupts the read.

...code including such directives could have been recognized as preferable to equivalent code without, and there would be little need for programs to be able to use such behavior without the directives. As it is, though, there's no defined means of accomplishing many things that programs need to be able to do.

BTW, a dialect based upon a "high-level assembler" abstraction model could accommodate most forms of useful optimizations if it the Standard's "abstract machine" state were treated as a cached form of the the ABI's machine state, requiring the use of explicit synchronization directives in places where "cache coherency" would otherwise be a problem. If such a model had been adopted in 1990, then...

I think fundamentally people who wanted to view C as a Fortran replacement developed an abstraction model based around that notion, and view aspects of the C Standard that are inconsistent with that model as defects in the Standard rather than their model; the proper way to resolve such issues would be to recognize a dialect which is consistent with the compilers' abstraction model, but also recognize the existence of a dialect that supports constructs that abstraction model cannot.

To process code in an efficient and correct manner, a compiler would need to be able to recognize that addresses may be substitutable for purposes of effective-address capculation, without being fully substitutable in all other ways as well.

The response was, if I recall, that compilers had no way of processing such constructs correctly without disabling a lot of optimizations.

extern int x[1],y[1];
int test(int *p)
{
    y[0] = 1;
    if (p==x+1)
        *p = 2;
    return y[0];
}

@AlexisKing Don't have a link handy, but check the output for

I'm really not sure how one can distinguish between programs that clang and gcc are designed to process meaningfully, and those which they process meaningfully only by happenstance.

Clang and gcc treat such a comparison as invoking "Anything can happen" UB except at -O0 and -Og. Bug reports were filed for both compilers, since the Standard expressly contemplates such comparisons and defines their behavior as described, but neither compiler even treats the construct in a manner consistent with having each execution of the comparison independently yield a value chosen from the set {0,1} in side-effect-free fashion.

@AlexisKing Unfortunately, there also doesn't seem to be any will to make the Standard match clang/gcc behavior nor vice versa. Given e.g. extern int x[1],y[1];, all standards through C18 make clear that implementations may at their leisure place x and y in a manner that would make (x+1)==y true throughout a program's execution, or in a manner that would make it false throughout a program's execution, but those would be the only possibilities.

I need to be off for awhile...

In any case, the world would fall apart if C weren't usable as a high-level assembler, since no other language provides the semantics that C was designed to provide, and compilers like clang and gcc usually manage to provide.

1990s compilers would generate efficient machine code when fed source code that fit well with a machine's native operations.

I would think it should mean "Generating code that's not significantly worse than what a relatively mindless translator would produce", however.

@AlexisKing You earlier stated "Clang does a pretty good job at not being stupid, at the very least." The only obstacle to a 1990s compiler outperforming clang when generating Cortex-M0 code for the function above is that the Cortex-M0 hadn't been invented yet.

The world today relies upon mountains of code which relies upon implementations behaving in a manner consistent with Ritchie's Language in more cases than mandated by the Standard, in order to accomplish tasks not contemplated by the Standard. Unfortunately, there is no formally recognized distinction between that language and Fortran-wannabe dialects of C.

(2) the address that's being dereferenced is the sum of the values in two other registers, and may thus use the [Rn,Rm] addressing mode without having to spend an instruction performing the addition. Apply those two things to an otherwise mindless translation of the code and one would achieve performance better than what clang manages.