Re: More reliable compilers (of some programming langauges) than GNAT

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 28/11/2017 02:09, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ov60fj$mt8$1@gioia.aioe.org...
>> On 23/11/2017 01:35, Randy Brukardt wrote:
> ...
>>> as they are a rather useless construct that mainly serves to
>>> introduce bugs (if the shared library gets updated out of sync with
>>> the rest of the program).
>>
>> There is no any alternative to shared libraries.
> 
> Of course there is: write your code to use nothing but the target OS
> facilities and Ada. (Yes, I know that Windows uses shared libraries to
> implement the OS interface, but that's not visible to a statically linked
> program.) That was always the requirement at RRS, and any time that we've
> deviated from it we've generally come to regret it.

It does not work for any services, which stretch far beyond core OS. 
Basically if we were in 60's and everything would be standard I/O, you 
could ditch shared libraries, but now practically nothing is 
read/write/ioctl, but a call to some entry point in some shared library.

> Statically linked programs are not going to fail because of some upgrade
> outside of botched OS upgrades (which are much less likely than other kinds,
> because most OS vendors are well aware of the havoc that they can cause).

If somebody changes the parameters of ioctl or position where you read 
from or contents of the read data, your application will fail just the 
same. It is no matter how an interface to some external entity looks 
like. If the interface changes or if the external entity changes, you 
have a problem. Shared libraries provide much better interfaces than 
I/O. So they won, which is a good thing.

> The supposed reasons for using shared libraries rarely hold any water (there
> aren't going to be dozens of nearly identical Ada programs running on a
> single machine at a single time).

This applies only to pure computational components which are in minority 
and usually quite stable, because there is little reason why you would 
change interface of some solver. The majority of shared libraries is a 
combination of computations with some "monitor" part dealing with the 
outer world. You cannot have it static, it is impossible because of the 
second part. You could try to separate computation from the monitor, but 
that does not really work. E.g. GTK started as a separation of 
computational GUI from X11 I/O. Then it became an I/O itself and you 
have the same old problem again. Unless you pack everything into the OS 
and hold it there, you have no chance. The last who did that was DEC, 
long gone and dead. (DEC systems had perfect shared libraries too.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de