The Development of the C Language
bell-labs.com
The Development of the C Language
1–10 of 24 posts
Re: The Development of the C Language
#2On 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 possibly change, but some important usages remain difficult to analyze. For example, functions with pointer arguments derived from arrays are hard to compile into efficient code on vector machines, because it is seldom possible to determine that one argument pointer does not overlap data also referred to by another argument, or accessible externally. More fundamentally, the definition of C so specifically describes the semantics of arrays that changes or extensions treating arrays as more primitive objects, and permitting operations on them as wholes, become hard to fit into the existing language.
Ritchie notes the difficulty with optimization and aliasing and as far as I know the only portable C89/99 convention for this is using the appropriate function if what you want to do is memcpy() or memmove().
I love C and programming is mostly a hobby for me. But my language experience does not really extend beyond C and C++, other than reading about D, Lisp, Rust, etc. I also think the STL is the beautiful thing C++ gave us, and having it as a library is better than building these structures into the language. The STL relies heavily on iterators of course.
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? As a hobbyist, I am more interested in something like slices from D or parameter type restrictions than trivially obvious global guarantees like ``if you mutably borrow it then there is no aliasing''. Do D programmers find the slices helpful and easy? Is the syntax and/or semantics such that the programmer can provide the compiler with aliasing info? Are there a small number of type concepts for this or does it explode with the number of different data structures.
I know there is the restrict keyword, but I have always been too lazy to use it in C and even in C++ it seems (quadratically?) unlikely you would be energetic enough to properly declare which pairs of entities could not alias.
Re: The Development of the C Language
#3"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."
Yet it took up all these years until clang for anyone to start taking static analysis seriously in C, and even now many still ignore it.
Re: The Development of the C Language
#4On 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…
> I also think the STL is the beautiful thing C++ gave us, [...]
It did not. STL was given to us by HP and SGI, and then C++ adopted STL into its standard library.
Re: The Development of the C Language
#5On 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.
Re: The Development of the C Language
#6On 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…
> I also think the STL is the beautiful thing C++ gave us, [...] It did not. STL was given to us by HP and SGI, and then C++ adopted STL into its standard library.
Alexander Stepanov gave STL to ANSI C++ working group, after implementing it originally in Ada 83.
What HP and SGI did was to provide the first C++ working implementations of it, outside the ANSI C++ working group work.
Re: The Development of the C Language
#7"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for…
Yet it took up all these years until clang for anyone to start taking static analysis seriously in C
In some circles maybe, but some industries have decades of experience applying static analysers to their C code, and companies have been selling static analysers throughout.
Re: The Development of the C Language
#8"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for…
Yet it took up all these years until clang for anyone to start taking static analysis seriously in C In some circles maybe, but some industries have decades of experience applying static analysers to their C code, and companies have been selling static analysers throughout.
Outside industries where MISRA-C is part of the daily vocabulary, I never seen any appreciation for C static analysers.
Re: The Development of the C Language
#9Earlier quoted context omitted.
Yet it took up all these years until clang for anyone to start taking static analysis seriously in C In some circles maybe, but some industries have decades of experience applying static analysers to their C code, and companies have been selling static analysers throughout.
Outside industries where MISRA-C is part of the daily vocabulary, I never seen any appreciation for C static analysers.
That is because you spend your whole day on HN instead of programming.
CPython for example is checked by coverity.
Re: The Development of the C Language
#10Earlier quoted context omitted.
> I also think the STL is the beautiful thing C++ gave us, [...] It did not. STL was given to us by HP and SGI, and then C++ adopted STL into its standard library.
Alexander Stepanov gave STL to ANSI C++ working group, after implementing it originally in Ada 83. What HP and SGI did was to provide the first C++ working implementations of it, outside the ANSI C++ working group work.
It would be nice if the STL would be a common denominator across a few languages.