Re: [dev] Suckless remote shell?

From: Alexander S. <>
Date: Thu, 7 Nov 2013 16:55:35 +0400

2013/11/7 Szabolcs Nagy <>:
> * Alexander S. <> [2013-11-07 04:27:26 +0400]:
>> Seriously, simple parametric types wouldn't hurt C. Not at all. No
>> need for that automatic pointer conversion, additional parameters to
>> sort() and alike, and such. (I'm going to make a confession, I really
>> think C would benefit from C++ templates, even in their current
>> state).
> c has no implicit pointer conversion other than for void*
> void* is important to represent pointers in a generic way,
> parametric types do not help with this, those assume a
> statically known type which is not always the case
> the way c++ eliminated the implicit conversion is actually
> less safe than the c semantics: in c++ one has to use casts
> to convert void* and this turns off the type-checker
> there are plenty source for void pointers: mmap, dlsym,
> context pointers for callbacks, etc. if you incorrectly
> assume in c that a pointer is void* then you get a type error,
> in c++ your cast will mask this error so it can go unnoticed,
> in c a cast is a code smell that alarms you, in c++ they are
> not uncommon at all in code interacting with the os, actually
> c++ has at least 4 different casts with different semantics
> based on what you cast, this is not how to improve safety

Well, in code interacting with low-level you are probably going to
meet just static_cast<>, which is everywhere, and reinterpret_cast<>,
that's reserved for casting pointers. I can argue about necessity of
these four types of casts (dynamic_cast<> is quite important for
safety, imo).
Context pointers for callbacks... well, they exist because of the
limitations of the type system. I'd rather see
žA,[Types...].pthread_create(pthread_t*, A(*callback)(Types...), Types
args...) (so, arbitrarily many additional args for callbacks). A
type-checker can properly check it, and even in current calling
conventions, it's quite fast to handle: you just copy a chunk of
memory fro and to stack, wholesale. Failing that, there's always
žA,B.pthread_create(pthread_t*, A(*callback)(B), B arg).
mmap is another matter, but whether for turning file into RAM or for
IPC, it tends to have some structure, I guess?

> parametric types have problems on their own: eg the type
> parameters have to be encoded into the name of the interface
> which gives rise to name mangling with all its warts
> (c++ name mangling is not specified so you get a fragile binary
> interface with names so long that the hash lookups by the elf
> dynamic loader becomes a bottleneck..)

Best regards,
Alexander S.
Received on Thu Nov 07 2013 - 13:55:35 CET

This archive was generated by hypermail 2.3.0 : Thu Nov 07 2013 - 14:00:09 CET