Request for help migrating the C Standard to a new Standard

[Rick C. Hodgin]

Supercat, I have tried to contact you in email before but I think you
are either ignoring my emails, or they aren't getting through, but I
specifically have you in mind when I write this post.

I would like to take the C Standard as a base, and rewrite it to be
a new standard for a new C language, one which would be a step toward
C++, but not the great leap made in C++ to get there.

I want this new standard to be in the same light and tone and vein as
C, but to introduce new features, to simplify the definition, and to
create the "core C" compiler and virtual environment available for
testing we've discussed before:

In this thread, and not necessarily this message:
https://groups.google.com/d/msg/comp.lang.c/ut6CnJ7NFlQ/R-kBLRAHxb0J

I want to have a real discussion about moving C forward from the
rigid standards body that exists today, to become a more flexible,
more agile language that is able to move with the changes in tech-
nology, the advancements made in language design, and to always
maintain its core C nature, but to incorporate features which do
operate in C as extensions that are part of the base language.

I would like to start by getting a list of some of the things Supercat
has identified over time, where he specifically states things like,
"The C Standard gives no guidance on..." or "The C Standard allows for
more than one interpretation here..." and so on.

-----
When complete, I want this new standard to become an alternate C
Standard that compiler developers can turn to and use as a real and
solid base.

I'm NOT asking for a CAlive thing here. That is separate. This is
to be a work toward a C-only new standard.

--
Rick C. Hodgin

[Mr. Man-wai Chang]

On 17/11/2017 10:50 PM, Rick C. Hodgin wrote:
> Supercat, I have tried to contact you in email before but I think you
> are either ignoring my emails, or they aren't getting through, but I
> specifically have you in mind when I write this post.
>
> I would like to take the C Standard as a base, and rewrite it to be
> a new standard for a new C language, one which would be a step toward
> C++, but not the great leap made in C++ to get there.

Reminder: you have the right to build your own C compiler.

For the established regular C most know, don't mess it up with bloat! :)

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[Kenny McCormack]

In article <oumuk4$8ar$1...@toylet.eternal-september.org>,

Mr. Man-wai Chang <toylet...@gmail.com> wrote:
>On 17/11/2017 10:50 PM, Rick C. Hodgin wrote:
>> Supercat, I have tried to contact you in email before but I think you
>> are either ignoring my emails, or they aren't getting through, but I
>> specifically have you in mind when I write this post.
>>
>> I would like to take the C Standard as a base, and rewrite it to be
>> a new standard for a new C language, one which would be a step toward
>> C++, but not the great leap made in C++ to get there.
>
>Reminder: you have the right to build your own C compiler.
>
>For the established regular C most know, don't mess it up with bloat! :)

Indeed. Note that this (what Rick proposes) has already been done.
IMHO, none of these attemps (some are listed below) has ever gained any
traction.

1) Jacob's super-enhanced version of C (lcc-win)
2) Walter Bright's super-enhanced version of C (D)

--
He must be a Muslim. He's got three wives and he doesn't drink.

[Mr. Man-wai Chang]

On 17/11/2017 11:49 PM, Kenny McCormack wrote:
>
> Indeed. Note that this (what Rick proposes) has already been done.
> IMHO, none of these attemps (some are listed below) has ever gained any
> traction.
>
> 1) Jacob's super-enhanced version of C (lcc-win)
> 2) Walter Bright's super-enhanced version of C (D)

Instead of trying to modify the fundamental syntax of existing C, maybe
Mr. Hodgin should build a high-level script language on top of C. A good
example is Visual Foxpro and Clipper the dBase compiler.

[Rick C. Hodgin]

On 11/17/2017 10:49 AM, Kenny McCormack wrote:
> 1) Jacob's super-enhanced version of C (lcc-win)

I don't know lcc-win, so I can't comment on it. I have agreed
with many of Jacob's points over the years, but not all of them.

> 2) Walter Bright's super-enhanced version of C (D)

D was a notable departure from C++, not C. I'm trying to create
a C which has some of what C++ defines, but not the way C++ defines
it, but more in a C-like way, and with some extensions addressing
issues with the existing C language in limitations, shortcomings,
or in missing features.

--
Thank you, | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count

[Rick C. Hodgin]

On 11/17/2017 10:58 AM, Rick C. Hodgin wrote:
> On 11/17/2017 10:49 AM, Kenny McCormack wrote:
> > 2) Walter Bright's super-enhanced version of C (D)
> D was a notable departure from C++, not C.

My mistake. I was told about D from a C++ developer, and he gave
me that foundation that D was a better C++. Something inside me
told me my post just now was not correct. In doing some research
just now I realize it was intended to be a better C from even the
beginning.

I apologize for the error.

[Thiago Adams]

On Friday, November 17, 2017 at 12:50:51 PM UTC-2, Rick C. Hodgin wrote:
...

> I'm NOT asking for a CAlive thing here. That is separate. This is
> to be a work toward a C-only new standard.

I will start by an easy item:

1 - struct initializers

struct X
{
enum E e = E1;
int i; //0 by default
int i2 = 1;
struct Point pt = {.x = 1, .y = 2};
struct Point pt2; //same of {}
};


X x = {}; //call the default initializer

This feature would remove many macros from my code.

The difference from C++ is that in C++ this expression is not
constant. I think its safer to be constant.

[Ian Collins]

On 11/18/2017 05:51 AM, Thiago Adams wrote:
> On Friday, November 17, 2017 at 12:50:51 PM UTC-2, Rick C. Hodgin wrote:

> ....

>> I'm NOT asking for a CAlive thing here. That is separate. This is
>> to be a work toward a C-only new standard.
>
> I will start by an easy item:
>
> 1 - struct initializers
>
> struct X
> {
> enum E e = E1;
> int i; //0 by default
> int i2 = 1;
> struct Point pt = {.x = 1, .y = 2};
> struct Point pt2; //same of {}
> };
>
>
> X x = {}; //call the default initializer
>
> This feature would remove many macros from my code.
>
> The difference from C++ is that in C++ this expression is not
> constant. I think its safer to be constant.

It can be if you make it so:

struct Point
{
int x {};
int y {};

constexpr Point() = default;
constexpr Point( int _x, int _y ) : x {_x}, y {_y} {}
};

enum E {E1};

struct X
{
enum E e = E1;

int i = 0; //0 by default
int i2 = 1;
struct Point pt = {1,2};

struct Point pt2; //same of {}
};

constexpr X x {};

[Thiago Adams]

This is what I don't like in C++:
Sample:

int v = 0;

struct X
{
int i = v;
};

int main()
{
v = 1;
X x = {};
cout<< x.i; //prints 1
}

I prefer that the initialization of i to be a constant expression
at definition of X.

[supe...@casperkitty.com]

On Friday, November 17, 2017 at 8:50:51 AM UTC-6, Rick C. Hodgin wrote:
> I want to have a real discussion about moving C forward from the
> rigid standards body that exists today, to become a more flexible,
> more agile language that is able to move with the changes in tech-
> nology, the advancements made in language design, and to always
> maintain its core C nature, but to incorporate features which do
> operate in C as extensions that are part of the base language.

One of the big problems with C is that people trying to standardize it
have sought to stamp out what made it useful in the first place: it wasn't
so much a single language as a way of constructing languages that were
suitable for use in different target platforms and application fields.
Given the range of targets and application fields, I would suggest that a
good standard should not try to mandate that all conforming implementations
support all conforming programs, but instead define a category of programs
which I would call "Selectively Conforming" with the semantics that a
conforming implementation may reject any (or even all) Selectively Conforming
programs, but must process in defined fashion every SC program that it does
not reject.

To be a little more precise, an implementation would be required to define
a set of environmental requirements and a set of failure actions, and
guarantee that if none of the environmental requirements are violated, the
implementation will *always* either behave as defined by the Standard or
perform one of the failure actions defined by the implementation. No
mushiness about what happens if translation limits are exceeded, etc.

Rather than have a single committee responsible for all extensions, I would
like to see a namespace convention for extensions, such that if the
designator ACME_C is assigned to the Acme C Compiler Company, then any
implementation which regards anything of the form __STDX_ACME_X_* as
anything other than an ordinary identifier must do so in a fashion defined
by the Acme C Compiler Company. If the Acme C Compiler Company has an idea
for a useful extension that uses identifiers of that form, publishes it,
and encourages other vendors to implement it, properly-written code which
uses that extension would have a compiler-independent meaning. Compilers
would not be required to support that meaning, but would not be allowed to
define those identifiers in a way contrary to it (so if code says

#ifndef __STDX_ACME_SUPPORT
#error Requires ACME extensions
#endif
__STDX_ACME_SUPPORT(1,4,3) // Code expects to use version 1.4.3 of
// ACME spec.
__STDX_ACME_INT_ADDRESSES()

and version 1.4.3 of the Acme spec says that integer-to-address conversions
will be performed in representation-conserving fashion, then any compiler
given the above would be required to either perform integer-to-address
conversions in representation-conserving fashion or refuse compilation
altogether.

Ideally the Standard would define common things like a way of specifying
commonplace address semantics rather than having many different compiler
vendors each define such a directive (thus making it necessary to have
implementations that seek maximum compatibility support many different
ways of saying the same thing) but even that would be better than not
having any compiler-independent way of specifying what is supposed to be
meant by an integer-to-pointer conversion.

[Ian Collins]

That is ... horrible.

--
Ian.

[Rick C. Hodgin]

Wouldn't the argument here be that in C today someone can essentially
do that with the inclusion of certain headers, and subsequent tests
for those features existing in regular C code?

My goals in creating a C-like offshoot standard are not so much to
change C at its core, but to do three real things:

#1 -- Provide guidance, a steering component, one which says,
"this is what the language should be moving toward based"
on expert consensus," rather than simply responding to
what other clever compiler authors may have already imple-
mented in their product, or in some cases that which has
already gained wide acceptance in multiple compilers.

#2 -- Relax some of the restrictions that no longer apply to
modern machines, such as adding an option to not require
forward declarations, to not require the "struct" keyword
in later uses (and without typedefs), adding a stronger
preprocessor, and requiring that the compiler engine be
opened up to allow legitimate language extensions as add-
ins or plug-ins to the parser itself. The internal format
of the compiler engine should be designed in such a way
that generic add-ons are possible, making add-on exten-
sions by anyone who wants to extend the language for their
special niche needs possible. That's the whole purpose of
my RDC framework, by the way ... is to make it a "rapid
development compiler" which is two-fold, in physically imp-
lementing the compiler, and in writing code in the lang-
uages the compiler supports.

#3 -- Introduce a handful of new features to C, such as the
basic class, exception handling, function overloading,
and to also make the compiler aware that it is only a
tool running on real hardware, and therefore has a
relationship to the developer allowing for a simple and
well-defined "debug mode" compile mechanism, that allows
for edit-and-continue to be applied to the runtime ABI.

I would like this to be done in C as it is, but I don't see anyone
related to any long-established component of C and the C Standards
group being willing to change anything along these lines.

As such, our only avenue is a new off-shoot of the language ... if
we want to go that route.

CAlive will be something different. In fact, I'm so upset over C
in its current limiting governing body that I may drop the C reference
and just call it Alive, or come up with some other name.

--
Rick C. Hodgin

[Kenny McCormack]

In article <46f90f96-78e6-469a...@googlegroups.com>,
Rick C. Hodgin <rick.c...@gmail.com> wrote:
...

>CAlive will be something different. In fact, I'm so upset over C
>in its current limiting governing body that I may drop the C reference
>and just call it Alive, or come up with some other name.

Yes, very good. I support that move. Among other things, it means you'll
stop trying to push it here - since it will then be completely OT here (as
it clearly already is, but this should make it clear enough even for you).

As far as new names, how about MyGodIsBetterThanYourGodAndYoureGoingToHell ?

--
The people who were, are, and always will be, wrong about everything, are still
calling *us* "libtards"...

(John Fugelsang)

[Rick C. Hodgin]

On Saturday, November 18, 2017 at 8:44:47 AM UTC-5, Kenny McCormack wrote:
> As far as new names, how about MyGodIsBetterThanYourGodAndYoureGoingToHell

Is your life really reduced to such mocking of other people, Kenny?
What will the book of the events of your life read on that final day
of judgment? "Kenny mocked person X. Kenny mocked person Y. Kenny
mocked. Kenny mocked."

Is that the world you want to live in, Kenny? One where we are
stabbing at each other in hate? Or do you want to live in a world
where we each reach out our hands where we have ability to try and
make the lives of those around us better?

I want to use that which God has given me to improve people's lives.
And I want to give Him His proper place in my life, which is at the
head of all things, up front, out front, where all can see that any
goodness I possess is not of me, but of Him living in me.

God offers us eternity and all there is. You would push that offer
away so you could mock Him, mock me, mock everybody with something
unholy living inside your dark heart? There is another way, Kenny,
and it's available to you too.

--
Rick C. Hodgin

[Rick C. Hodgin]

On Saturday, November 18, 2017 at 8:44:47 AM UTC-5, Kenny McCormack wrote:

> In article <46f90f96-78e6-469a...@googlegroups.com>,
> Rick C. Hodgin <rick.c...@gmail.com> wrote:
> ...
> >CAlive will be something different. In fact, I'm so upset over C
> >in its current limiting governing body that I may drop the C reference
> >and just call it Alive, or come up with some other name.
>
> Yes, very good. I support that move. Among other things, it means you'll
> stop trying to push it here - since it will then be completely OT here (as
> it clearly already is, but this should make it clear enough even for you).

I'm not here to take cues from you, Kenny, nor from any other mocker
or hater. Those who want to damage any efforts to step up and step
forward for God are not the driving force in our efforts. We serve
a higher purpose, a higher calling.

You can mock and demean and post slanderous taglines about me and do
all other manner of hateful things toward me you want to, but in the
end it will only reflect upon you and your core character as I, even
under the duress of ongoing attacks, continue on seeking to serve the
Lord, and all you can do is rise up with demolition equipment and try
and topple that which is being built up.

It's a wretched existence you're in pursuit of, Kenny. There is a
far better way and I advise you to pursue it because it will not only
benefit you, but everyone around you.

Consider eternity, Kenny. Consider the hours you have left in this
world for labor and effort given over. Look at it as a countdown
timer. If you're 40 and your family generally lives to age 75, then
you have 35 years left. Look at those years as a countdown timer.

35 years might seem like a long time, but that's all you've got. The
day of your appointment with eternity is secured, and it may not come
at age 75. One drunk driver at an intersection and you die at age 42
unexpectedly. One satellite falling from the sky and landing on your
house and that's it. One unexpected airline disaster and it's over.

You are on borrowed time.

Try and keep that perspective in mind as you go through your days.
You're going to leave this world at some point ... and then what?
Your legacy will be mocking and hate and tearing and ripping down all
that people tried to rise up around you in good intentions, or is it
just those things which are in service to the Lord?

You can use those remaining years as the gift God intends them to be:
to work for Him, to move toward those things which are of Him, for Him,
that WILL ENDURE beyond the limits and confines of this temporal world:

See vs. 14 and 15:
https://www.biblegateway.com/passage/?search=1+Corinthians+3%3A11-15&version=KJV

God gives you the opportunity to thrive, Kenny, both in this world,
and in eternity. It is His offering to all of His creation. But for
those who only want hate, who only want to do harm, who only want to
tear down what others are trying to create and build up ... there will
be no such ending, but only the eternal confinement He's prepared for
those who only want to do harm.

You should investigate these things, Kenny. You only have N years
left ... if indeed you do have that full extent of time.

--
Rick C. Hodgin

[Gareth Owen]

gaz...@shell.xmission.com (Kenny McCormack) writes:

> In article <46f90f96-78e6-469a...@googlegroups.com>,
> Rick C. Hodgin <rick.c...@gmail.com> wrote:
> ...
>>CAlive will be something different. In fact, I'm so upset over C
>>in its current limiting governing body that I may drop the C reference
>>and just call it Alive, or come up with some other name.
>
> Yes, very good. I support that move. Among other things, it means you'll
> stop trying to push it here - since it will then be completely OT here (as
> it clearly already is, but this should make it clear enough even for you).

I've always thought "Clive" was a good name

[fir]

i would like if rick would publish it under the name "IamBrialnlesIdiot" (IamBrialnlesIdiot language)

[Rick C. Hodgin]

Get it right, fir. It's "IamBrainlessIdiot" or maybe IBI for short? :-)
Maybe I'll call it "Ibi" in deference to you. :-) "What's your code
written in?" "Ibi." "Ibi? What's that?" "It's fir's attempt to
disparage me." "Who's fir?" "Long story." :-)

Still, you do better in English than I would do in your native
language. I give you props for your general ability to communicate
in English. We always understand what you're saying, even if it's
not in full and proper English grammar, nor the nicest things being
communicated. :-)

--
Rick C. Hodgin

[fir]

it is not an attempt stupid sad idiot.. it just greatly fits

[Rick C. Hodgin]

On Saturday, November 18, 2017 at 10:47:40 AM UTC-5, fir wrote:
> it is not an attempt stupid sad idiot.. it just greatly fits

If you want to know the truth about why it seems that way, then I
offer it to you:

https://www.biblegateway.com/passage/?search=1+Corinthians+2%3A14&version=KJV

14 But the natural man receiveth not the things of the Spirit of
God: for they are foolishness unto him: neither can he know
them, because they are spiritually discerned.

God is spirit. Knowledge of Him doesn't come through our natural
senses, but spiritually. That's not something we can attain on our
own. God has to change us. And for all who will seek the truth,
God examines our heart and knows we are seeking the truth, He then
makes that change for us so we can find it.

You can read more in John 3 if interested, specifically verse 5:

https://www.biblegateway.com/passage/?search=john+3&version=KJV

--
Rick C. Hodgin

[supe...@casperkitty.com]

On Saturday, November 18, 2017 at 7:26:21 AM UTC-6, Rick C. Hodgin wrote:
> On Friday, November 17, 2017 at 4:53:30 PM UTC-5, supe...@casperkitty.com wrote:
> > Ideally the Standard would define common things like a way of specifying
> > commonplace address semantics rather than having many different compiler
> > vendors each define such a directive (thus making it necessary to have
> > implementations that seek maximum compatibility support many different
> > ways of saying the same thing) but even that would be better than not
> > having any compiler-independent way of specifying what is supposed to be
> > meant by an integer-to-pointer conversion.
>
> Wouldn't the argument here be that in C today someone can essentially
> do that with the inclusion of certain headers, and subsequent tests
> for those features existing in regular C code?

Having code specify what it needs, and having a compiler balk at a
specification it can't meet, is better than having code test whether
an implementation can meet its need, in at least two major ways:

1. Quality implementations may be able to adjust their configuration
automatically in response to directives that indicate requirements.

2. It would be practical to have an UB sanitizer silently ignore things
like integer overflow within code that is marked with directives that
would specify the behavior thereof behavior, while squawking at
overflows that occur in code not thus marked. It would, by contrast,
be much harder to make a sanitizer behave reliably with code that
relies upon feature tests and #error directives. If enabling an
overflow sanitizer would cause a compiler to report that it doesn't
guarantee anything about overflow behavior, code that relies upon
wrapping behavior wouldn't be able to run without the sanitizer
disabled. If the sanitizer is disabled, it would have no way to
detect modules which accidentally omitted the "refuse to compile on
implementations that don't guarantee overflow behavior" logic.

I would like to see the Standard defined in such a way that existing
compilers that support the required behaviors could be made compatible
with code that requires them, merely by writing a compiler-specific
header file that would then satisfy the requirements of the Standard
with most such code, and would be usable with the vast majority (though
in some cases it might be necessary to predefine a macro that would
bypass the safety checks; such bypassing would violate a requirement
that implementations reject code whose demands they cannot meet, but
would allow programs to be used on implementations which are known to
meet requirements in all cases that matter).

[Rick C. Hodgin]

On Monday, November 20, 2017 at 1:11:29 PM UTC-5, supe...@casperkitty.com wrote:
> On Saturday, November 18, 2017 at 7:26:21 AM UTC-6, Rick C. Hodgin wrote:
> > On Friday, November 17, 2017 at 4:53:30 PM UTC-5, supe...@casperkitty.com wrote:
> > > Ideally the Standard would define common things like a way of specifying
> > > commonplace address semantics rather than having many different compiler
> > > vendors each define such a directive (thus making it necessary to have
> > > implementations that seek maximum compatibility support many different
> > > ways of saying the same thing) but even that would be better than not
> > > having any compiler-independent way of specifying what is supposed to be
> > > meant by an integer-to-pointer conversion.
> >
> > Wouldn't the argument here be that in C today someone can essentially
> > do that with the inclusion of certain headers, and subsequent tests
> > for those features existing in regular C code?
>
> Having code specify what it needs, and having a compiler balk at a
> specification it can't meet, is better than having code test whether
> an implementation can meet its need, in at least two major ways:
>
> 1. Quality implementations may be able to adjust their configuration
> automatically in response to directives that indicate requirements.

That's possible, but the features you'd be enabling wouldn't otherwise
exist in a compilation without the enabling factor. So the only direct
contact they'd have would be the fringe connection on the interface
between the two portions, and that could be handled reasonably well-
enough for all but exceedingly performance critical implementations
with the linker and the external .lib/.obj file I'd think.

> 2. It would be practical to have an UB sanitizer silently ignore things
> like integer overflow within code that is marked with directives that
> would specify the behavior thereof behavior, while squawking at
> overflows that occur in code not thus marked. It would, by contrast,
> be much harder to make a sanitizer behave reliably with code that
> relies upon feature tests and #error directives. If enabling an
> overflow sanitizer would cause a compiler to report that it doesn't
> guarantee anything about overflow behavior, code that relies upon
> wrapping behavior wouldn't be able to run without the sanitizer
> disabled. If the sanitizer is disabled, it would have no way to
> detect modules which accidentally omitted the "refuse to compile on
> implementations that don't guarantee overflow behavior" logic.

Wouldn't it be desirable to have those UB sanitizers report on their
full range of findings, and then run them through a post-parser that
identifies, based on knowledge of the locations for code blocks in the
live/running ABI, that they are known? I would think all such cases
would want to be reported on, and then flagged as being known, rather
than be flagged as being known and then not reported on.d

> I would like to see the Standard defined in such a way that existing
> compilers that support the required behaviors could be made compatible
> with code that requires them, merely by writing a compiler-specific
> header file that would then satisfy the requirements of the Standard
> with most such code, and would be usable with the vast majority (though
> in some cases it might be necessary to predefine a macro that would
> bypass the safety checks; such bypassing would violate a requirement
> that implementations reject code whose demands they cannot meet, but
> would allow programs to be used on implementations which are known to
> meet requirements in all cases that matter).

I have a similar view, but I look at it as introducing add-ons to the
actual compiler, those which then are able to parse new syntax or new
directives that weren't part of the baseline compiler.

In this way, everything becomes part of the compiler, and there isn't
really an enabler, unless you want to implement it that way, but
rather when you launch the compiler you specify which language(s) you
want to support with their features added to the compile-time compiler
database, so that when you specify certain languages, or ceratin
extensions of languages, then those feature are just automatically
enabled.

In my view, you would be shifting the burden of compilation from
source code to compiler-line directives, though it could also be done
in source code, but I honestly think that's the back-door way to do
it. The source code should be written for the target, and there
should be an external framework of some kind (a project with project
settings, for example), which then has information about how to do
the compile, how to link, how to import, how to export, etc.

--
Rick C. Hodgin

[supe...@casperkitty.com]

On Monday, November 20, 2017 at 12:19:57 PM UTC-6, Rick C. Hodgin wrote:
> > 2. It would be practical to have an UB sanitizer silently ignore things
> > like integer overflow within code that is marked with directives that
> > would specify the behavior thereof behavior, while squawking at
> > overflows that occur in code not thus marked. It would, by contrast,
> > be much harder to make a sanitizer behave reliably with code that
> > relies upon feature tests and #error directives. If enabling an
> > overflow sanitizer would cause a compiler to report that it doesn't
> > guarantee anything about overflow behavior, code that relies upon
> > wrapping behavior wouldn't be able to run without the sanitizer
> > disabled. If the sanitizer is disabled, it would have no way to
> > detect modules which accidentally omitted the "refuse to compile on
> > implementations that don't guarantee overflow behavior" logic.
>
> Wouldn't it be desirable to have those UB sanitizers report on their
> full range of findings, and then run them through a post-parser that
> identifies, based on knowledge of the locations for code blocks in the
> live/running ABI, that they are known? I would think all such cases
> would want to be reported on, and then flagged as being known, rather
> than be flagged as being known and then not reported on.d

Many kinds of UB can only be detected at runtime, and thus sanitizers
generate code which traps if they occur. In C#, if one writes:

int mul_add_semi_checked(int x, int y, int z)
{
int checked_product, unchecked_product
unchecked {
unchecked_product = x*y;
}
checked {
checked_product = x*z;
}
return unchecked_product + checked_product;
}

The function will generate code that is guaranteed to silently wraps around
if the first multiply overflows and is guaranteed to trap if the second
multiply overflows. If the addition overflows the behavior would be
controlled by compiler configuration.

A directive to demand clean wrap-around behavior, or demand trapping
behavior, could be supported by either limiting its effects to code
within the directive, or by squawking if the compiler wasn't configured
as needed; a compiler wanting to support code like the above where
no single set of semantics could satisfy all requirements would need to
handle such effects locally; compilers that couldn't handle that would
be allowed to simply reject such code instead. Support for such code
would be a QoI issue rather than a requirement.