Re: reliability features and Optimization techniques

On 26/04/2019 09:33, alexfrunews@gmail.com wrote:
> On Thursday, April 25, 2019 at 1:14:54 PM UTC-7, Martin Ward wrote:
> ...
>> With the current situation, anyone wanting to avoid
>> undefined behaviour (and don't we all?) has to write code like
>> this for any signed operation:
>>
>> signed int sum;
>> if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
>> ((si_b < 0) && (si_a < (INT_MIN - si_b)))) {
>> /* Handle error */
>> } else {
>> sum = si_a + si_b;
>> }
>
> In this day and age it is a shame that the language 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)


I've drawn up my own lists of things that I think ought to be in a
language like C, many dozens of them. But I realise they are never going
to be in C itself, whose design is pretty much frozen. (I'm implemented
most on my own projects.)


They don't however include any of the things you've listed. Like,
overflow checks: what would be the purpose, and what could a program do
if overflow is detected at runtime?


Not sure what you mean by the next two items. As for rotation (I assume
bit-rotation of int types); I had such operators many years ago, but
never used them.


Arbitrary precision - even if limited to a pre-set length - I feel
doesn't belong at this level of language. A C-like language can be used
to /implement/ such arithmetic elsewhere; it doesn't need it itself!


It would also demand other things that are not in the language. Remember
that C itself is barely capable of defining basic integer types, or of
printing them out:


Is int64 written as 'long int', 'long long int' or 'int64_t'? You might
find that 'int64_t' is an alias for one of the former, but which one? To
print an int64_t type might require a "%ld" format, or a "%lld" one, and
in practice means using PRId64. What macro gives int64's maximum value?
There will be several. And all this requiring various assorted headers.


If anything, C could do with tightening up and removing or restricting
features, rather than adding more.




Jan Ziak wrote:
  >> 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...


Yes, that's a feature I call a slice, which is a pointer and length.
That would be quite useful, except that typical C doesn't even use
arrays properly:


Instead of a function parameter being of type T(*)[] (pointer to array
of T), usually it is just T* (pointer to its element type). The array is
implied, which means it is possible to pass a pointer to anything: a
single T value; 2 successive T members of a struct. Or even just the
middle of an array.


It is undisciplined, with the 'length' of the implied array of such a
pointer being badly defined. (It can't even be the bounds of an
allocated memory block, because that can be bigger than the array.)


So C is pretty much a lost cause.


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


You mean having to have multiple definitions/declarations of variables
and functions that are shared across modules? I always found it crazy
that you can just write 'int a,a,a,a,a,a,a,a;' and the compiler says
nothing, but that is apparently necessary to make C's approach possible:


        int a; # in a shared header included by this module
        int a; # in the main module


Fixing that however would be a massive job (it really needs proper
modules) and would be ineffective, since the language must be backwards
compatible, so the old stuff is still there, and everyone will keep
using that. You've just made the language even more of a mess.


The solution would be to start again with something that does need to be
compatible, but which will create its own problems (it needs to interact
with billions of lines of existing C programs).


(Plenty of new languages like that but they tend to be heavyweight, and
have their own issues.)

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