Scenario: OpenSSL in D language, pros/cons

[Paulo Pinto via Digitalmars-d]

On Monday, 5 May 2014 at 08:04:24 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
> On Mon, 05 May 2014 07:39:13 +0000
> Paulo Pinto via Digitalmars-d <digitalmars-d at puremagic.com> 
> wrote:
>> Sometimes I wonder how much money have C design decisions cost
>> the industry in terms of anti-virus, static and dynamic 
>> analyzers
>> tools, operating systems security enforcements, security 
>> research
>> and so on.
>>
>> All avoidable with bound checking by default and no implicit
>> conversions between arrays and pointers.
>
> Well, a number of years ago, the folks who started the codebase 
> of the larger
> products at the company I work at insisted on using COM 
> everywhere, because we
> _might_ have to interact with 3rd parties, and they _might_ not 
> want to use
> C++. So, foolishly, they mandated that _nowhere_ in the 
> codebase should any
> C++ objects be passed around except by pointer. They then had 
> manual reference
> counting on top of that to deal with memory management. That 
> decision has cost
> us man _years_ in time working on reference counting-related 
> bugs. Simply
> using smart pointers instead would probably have saved the 
> company millions.
> COM may have its place, but forcing a whole C++ codebase to 
> function that way
> was just stupid, especially when pretty much none of it ever 
> had to interact
> directly with 3rd party code (and even if it had, it should 
> have been done
> through strictly defined wrapper libraries; it doesn't make 
> sense that 3rd
> parties would hook into the middle of your codebase).


So the decision was made and CComPtr<> and _com_ptr_t<> weren't 
used?!

I feel your pain. Well, now the codebase is WinRT ready. :)

>
> Seemingly simple decisions can have _huge_ consequences - 
> especially when that
> decision affects millions of lines of code, and that's 
> definitely the case
> with some of the decisions made for C. Some of them may have be 
> unavoidable
> give the hardware situation and programming climate at the time 
> that C was
> created, but we've been paying for them ever since. And 
> unfortunately, the way
> things are going at this point, nothing will ever really 
> overthrow C. We'll
> have to deal with it on some level for a long, long time to 
> come.
>
> - Jonathan M Davis


I doubt those decisions really made sense, given the other system 
programming languages at the time. Most of them did bounds 
checking, had no implicit conversions and operating systems were 
being written with them.

Algol 60 reference compiler did not allow disabling bounds 
checking at all, for example.

Quote from Tony Hoare's ACM award article[1]:
"A consequence of this principle is that every occurrence of
every subscript of every subscripted variable was on every 
occasion
checked at run time against both the upper and the lower declared
bounds of the array. Many years later we asked our customers 
whether
they wished us to provide an option to switch off these checks in 
the
interests of efficiency on production runs. Unanimously, they 
urged
us not to--they already knew how frequently subscript errors occur
on production runs where failure to detect them could be 
disastrous.
I note with fear and horror that even in 1980 language designers 
and
users have not learned this lesson. In any respectable branch of
engineering, failure to observe such elementary precautions would 
have
long been against the law."


[1]http://www.labouseur.com/projects/codeReckon/papers/The-Emperors-Old-Clothes.pdf