> Except there are other safer languages to choose from, like Pascal and Basic compilers.
I'm curious, why do you say "safer"? These are languages for microcontroller programming. The things you do there are bound to be "unsafe", like peeking and poking memory for memory mapped i/o and disabling/enabling interrupts.
Unless, of course, all the possible things (i/o, timers, interrupts, etc) are wrapped in some kind of "safe" api so you essentially don't have access to low level facilities any more. The Arduino programming environment is kinda like this but you can still cause bad things to happen and if all else fails, hang the device with an infinite loop.
> I'm curious, why do you say "safer"? These are languages for microcontroller programming. The things you do there are bound to be "unsafe", like peeking and poking memory for memory mapped i/o and disabling/enabling interrupts.
There are things which are inherently safe by design in languages like Pascal -- e.g. in a naively-written program you can't write past the boundary of the UART RX buffer and thrash some other array in your program -- but your observation is fair.
> There are things which are inherently safe by design in languages like Pascal -- e.g. in a naively-written program you can't write past the boundary of the UART RX buffer and thrash some other array in your program -- but your observation is fair.
Which, of course, you can accomplish in C by wrapping your UART buffer handling code in functions that do bounds checking. And I assume that a micro controller Pascal or Basic dialect will have some kind of peek/poke from/to arbitrary memory addresses that can be misused just as a pointer access in C.
Safety is hard to quantify and measure and calling one language safer than another sounds more like an opinion than a factual claim, especially in this context.
The "out of the box" defaults of Pascals are something you have to explicitly develop, test and maintain in your C. Which means that even during the maintenance cycle, long after it's originally implemented, it can still break in your C.
> The "out of the box" defaults of Pascals are something you have to explicitly develop, test and maintain in your C. Which means that even during the maintenance cycle, long after it's originally implemented, it can still break in your C.
Let's not confuse languages and libraries/apis here (that may or may not be shipped with the compiler). There are libraries for C and related languages (e.g. Arduino) that actually do give you a "safe" way to deal with the hardware on microcontrollers.
It's still easy to shoot yourself in the foot in C with a bad pointer access (esp. because there are no helpers to work with strings) but I don't really see how a Pascal dialect with peek/poke would be inherently better.
I do agree that buying one of these Pascal/Basic software products that come with a fancy standard library that does safe access to the hw may help writing safer software but I don't see how that is an inherent quality of the language.
Don't you think that pascal's standard safeties will prevent mistakes ?
1) array bounds checking (which can be used for safe hardware access instead of peek/poke)
2) pascal-style strings (with actual support for them, both in the language and in the standard library) (meaning a missing \0 doesn't erase the entire memory)
> 1) array bounds checking (which can be used for safe hardware access instead of peek/poke)
How? Peek/poke at the wrong address will generate an error in any case, and any MMU-less platform worth using will have the memory-mapped peripherals into a lower region, where it doesn't get thrashed by writing past the end of a buffer. I have seen bugs occurring because of data located past a buffer getting thrashed, but I don't remember seeing one in the context of hardware access.
> 2) pascal-style strings (with actual support for them, both in the language and in the standard library) (meaning a missing \0 doesn't erase the entire memory)
That shouldn't happen in C, i.e. there are library routines you should use so that it doesn't happen. Not that string processing isn't a pain :-).
> 3) type-safe pointers
No complaints here :-)
> 4) no pointer arithmetic
That's not always good, but it does decrease the likelihood of certain types of bugs, so yep!
It happens every day and it will as long as there's C. Zero-terminated strings are part of the standard library and almost infinite number of other libraries. You can't pretend it doesn't exist as the most common convention.
Additionally all those safety mechanisms can be turned off for performance, but only on the exact spot where it really matters, instead of being scattered all around the code.
var
EGAVGAScreen : Array[0..41360] of Byte absolute $A000:0000;
Et voila : bounds-checked memory mapped hardware access.
(note: the very well known "Crt" unit uses a memory mapped video buffer like this. So if you programmed a turbo pascal program, chances were good it was using this trick for screen output. Advantage : the speed is unbeatable)
> Which, of course, you can accomplish in C by wrapping your UART buffer handling code in functions that do bounds checking.
Of course, and you pay other hefty prices in Pascal or Basic for getting this sort of stuff "out of the box". Pascal isn't my favourite systems programming language, either :-).
There are zero features in C that Pascal and Basic dialects for system programming don't support. The only difference is that you need to turn safety off explicitly.
I was doing low level coding in Turbo Pascal before I even cared about C.
In terms of performance? None, assuming a well-written compiler. Depending on dialect you run into other issues though, such as the array size being part of the type signature, which is definitely not nice. The lack of adequate tooling and portability is another issue. Not strictly a problem of the language itself, but a problem you end up facing if you write low-level code in Pascal.
Don't get me wrong, I wrote low-level code in Pascal, too. It's nice and I probably wouldn't grumble too much if I had to do it again, but there's a bunch of stuff that comes in the same package with using something other than a language widely considered adequate for systems programming.
I do conceed that even though bashing C is a pasttime of mine, I would use it if it is the best option for a given project, depending on the set of factors to be considered for the said project.
In real life projects, there should be no place for tooling religion anyway,
I'm curious, why do you say "safer"? These are languages for microcontroller programming. The things you do there are bound to be "unsafe", like peeking and poking memory for memory mapped i/o and disabling/enabling interrupts.
Unless, of course, all the possible things (i/o, timers, interrupts, etc) are wrapped in some kind of "safe" api so you essentially don't have access to low level facilities any more. The Arduino programming environment is kinda like this but you can still cause bad things to happen and if all else fails, hang the device with an infinite loop.
Is there any backing for such claims of "safety"?