Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: 0xe2.0x9a.0x9b@gmail.com
Newsgroups: comp.compilers
Subject: Re: Optimization techniques
Date: Sat, 27 Apr 2019 04:56:45 -0700 (PDT)
Organization: Compilers Central
Lines: 67
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <19-04-032@comp.compilers>
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-020@comp.compilers> <19-04-025@comp.compilers>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="89966"; mail-complaints-to="abuse@iecc.com"
Keywords: performance, debug
Posted-Date: 27 Apr 2019 10:19:32 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
In-Reply-To: <19-04-025@comp.compilers>
Xref: csiph.com comp.compilers:2216

On Friday, April 26, 2019 at 9:11:46 PM UTC+2, alexf...@gmail.com wrote:
> In this day and age it is a shame that the language [C] that is still very
> much alive does not provide the programmer with easy-to-use (and
> implement!) tools to perform/handle:
>
> - overflow checks like the above for +, -, *, /,
>   %, <<, both signed and unsigned
> - mathematically meaningful comparison of signed
>   and unsigned integers
> - arithmetic right shift out of the box
> - ditto rotation
> - arbitrary precision arithmetic (for integers
>   of compile-time-constant length)
> - endianness at last
> - (I probably forget many more)

Hi. In my opinion, the C extensions you are requesting would just turn C into
C++ which allows the programmer to create a new class/struct and overload the
arithmetic operators.

> Often times the desired functionality is already in the CPU

With a Turing-complete CPU, any desired functionality is already in the CPU.

The only distinctions between Turing-complete CPUs are: performance, distance
to solutions (aka programming convenience).

> or needs
> just a few more instructions but there's no simple, short and standard
> way to tell the compiler to generate the code for the common problem.
> It's always compiler extensions (or dependencies on specific
> compilers), #ifdefs, inline (and non-inline) assembly, code like shown
> above, reinvented wheels all the way, over and over again, from
> project to project.  I understand that C is minimalistic, but I think
> it needs to step up a bit.
>
> When I'm handling arbitrary, potentially maliciously crafted data, I
> want to have those overflow checks, but I don't want to be burdened
> with what the compiler can easily do for me but fails to deliver year
> after year just because it's not in the language.
>
> What may have been deemed sufficient back in the 80's is no more.
> Because the Internet.  Deprecating gets() is nice but doesn't quite
> cut it.
>
> Alex

I don't fully understand. Are you suggesting to add buffer overflow checks to
the C language? When developing a C compiler, clearly it *is* possible to
transparently add those checks to C when the compilation target is something
like a virtual machine, the compiler&runtime just need to know which functions
are allocating and freeing memory.

Performance of the code generated by the compiler you seem to be requesting
depends on the choice of the physical representation of C pointers. The C
compiler can generate code performing buffer overflow checks even if pointer
size is unchanged from the traditional 4 or 8 bytes.

When calling assembly code from C, the C compiler can run the assembly code in
a virtual machine and thus can perform safety checks in a lot of cases. This
is clearly possible to implement, and the only factor here is performance.

Summary: If sacrificing performance is OK, it is possible to transparently
implement any imaginable kind of a safety measure.

Sincerely
Jan