The Development of the C Language • Hacker News Board

Re: The Development of the C Language

#21

Post by _5ysi » Thu, Aug 31, 2017, 7:02 PM UTC

pjmlp wrote: post #5

_5ysi wrote: post #2

On the other hand, C's treatment of arrays in general (not just strings) has unfortunate implications both for optimization and for future extensions. The prevalence of pointers in C programs, whether those declared explicitly or arising from arrays, means that optimizers must be cautious, and must use careful dataflow techniques to achieve good results. Sophisticated compilers can understand what most pointers can p…

Well, Ada forces aliasing to be explicitly requested. You see an example here https://gcc.gnu.org/onlinedocs/gnat_ugn/Aliased-Variables-an... To use C vocabulary, Ada always assumes restrict unless you make use of aliased , and it is a compile error to handle it otherwise.

Wow Ada syntax is not what I'm used to! This is interesting; it seems like a very simple solution to make the problem less widespread. It is still on you though to use the correct version of the equivalents of memcpy() and memmove() though?

Re: The Development of the C Language

#22

Post by Koshkin » Thu, Aug 31, 2017, 8:20 PM UTC

cntlzw wrote: post #13

I love stories like this. All the history behind a very young but rich science. For example I always assumed C came from a strong typing background and its premises was always about being portable. Neither of them are true.

C was designed to be more portable than assembler. In fact, that was one of its raisons d'être. It is not hard to imagine that other programming languages (COBOL, Ada, Common Lisp, Perl) could be more portable than C, but still.

Re: The Development of the C Language

#23

Post by pjmlp » Fri, Sep 01, 2017, 6:57 AM UTC

_5ysi wrote: post #21

pjmlp wrote: post #5

Earlier quoted context omitted.

Well, Ada forces aliasing to be explicitly requested. You see an example here https://gcc.gnu.org/onlinedocs/gnat_ugn/Aliased-Variables-an... To use C vocabulary, Ada always assumes restrict unless you make use of aliased , and it is a compile error to handle it otherwise.

Wow Ada syntax is not what I'm used to! This is interesting; it seems like a very simple solution to make the problem less widespread. It is still on you though to use the correct version of the equivalents of memcpy() and memmove() though?

Ada has not stand still, the latest standard revision is from 2012.

http://www.ada2012.org/

It has all the modern goodies in it, OOP, interfaces, contracts alongside type safety.

Then if you really care about high integrity systems, there is its brother SPARK, which is a hardened version of Ada, the latest revision being from 2014.

http://www.spark-2014.org/

Regarding calling memcpy() and memmove(), the compilers should be able to produce the right kind of code.

Now if you really mean the C functions, the aliasing declaration should be part of declaration.

Not sure what is the current state of Ada's POSIX specification.

Re: The Development of the C Language

#24

Post by _5ysi » Sat, Sep 02, 2017, 8:02 PM UTC

adwn wrote: post #14

_5ysi wrote: post #2

On the other hand, C's treatment of arrays in general (not just strings) has unfortunate implications both for optimization and for future extensions. The prevalence of pointers in C programs, whether those declared explicitly or arising from arrays, means that optimizers must be cautious, and must use careful dataflow techniques to achieve good results. Sophisticated compilers can understand what most pointers can p…

> My question to HN is: do any languages that really emphasize pointers and iterators over arrays and indices have a non-cumbersome way of telling the compiler when no aliasing is expected? Rust has this concept baked into the language: any mutable reference is statically guaranteed to not alias anything else that is accessible. Non-mutable references can alias each other, but I don't think there are any optimization…

Yeah, this is the gist of my question. Basically if programming language inc(C) has an overloaded function for both memcpy(alias...) and memmove(restrict...), how does the type information enter the system which allows the compiler choose the correct procedure?

I'm interested in any language innovations that have a smooth, suave feature for this. Rust changes the default, but in some sense its not an absolute improvement; where C bluntly assumes memmove(), Rust bluntly applies memcpy().