Re: C language andOptimization techniques

On Saturday, April 27, 2019 at 7:19:34 AM UTC-7, Jan Ziak wrote:
> 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.


I did not say or mean that. One big thing I dislike about C++ is that
it's not just a bigger language, it's much more complex, with lots of
implicit things and many more things interacting with or affecting one
another. I would not advocate for having more of that in C.


The things that I mentioned above are conceptually simple (often
trivial), not changing the nature of the language, just giving it a
few more tools for solving common problems, tools that people need to
reinvent since they aren't part of the library or core language. Just
like the trunc() and round() functions that were included in C99 for
the first time. Simple things that don't need to be reinvented
needlessly, things that can possibly be implemented with bugs every
time. I'm mostly talking about this kind of language extension.
Conceptually simple things done right and available out of the box.


> > 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).


You can call it convenience. It doesn't make it useless or
undesirable. It can cut costs (think of security costs as well, not
just the ability to churn out code more quickly simply because the
language/library is rich).


> > 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?


No. However, I think the language could provide a designated
tuple-like type containing a pointer and a count/size and maybe some
functions/macros to check the range. Or something like that. But...


What I primarily had in mind was things like complex data structures
of variable size, which contain counts/ sizes, indices and such.
Consider your favorite multimedia file formats or file systems. Proper
parsing includes checking of those, including for overflows.


I have seen some file system and driver code written in C. I've seen
some bad code that desperately lacked those checks, had them wrong or
insufficient.


I'd want the language to help me perform these important checks. But
it doesn't. The language forces me to manually write the
functions/macros (or inline code) to perform these checks for all
relevant types. You get undefined behavior for free for all types
alright. Most CPUs provide defined overflow control for multiple
types and ALU operations, but you can't get it because there's no way
to express it in the language. It is an insult to the programmer.


Just because K&R never checked for overflows or did it by hand,
doesn't mean we should keep the tradition 30+ years later. The
language and compilers can do it for us. Mundane stuff like this
should be done by machines, not people (hello to C++'s "one definition
rule", which must have been checked by the compiler too, but no, in
projects of many thousands lines of code it's humans to somehow keep
track of improper redefinitions that cause undefined behavior, how
sane is that?).


Alex

Return to the comp.compilers page.
Search the comp.compilers archives again.