Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on July 19, 2021 1:03 am wrote:
> FrankHB (frankhb1989.delete@this.gmail.com) on July 17, 2021 1:44 am wrote:
> > Anon (no.delete@this.spam.com) on July 16, 2021 12:01 pm wrote:
> > > FrankHB (frankhb1989.delete@this.gmail.com) on July 16, 2021 6:43 am wrote:
> > > > For example, the abuse of explicitly fixed-width machine
> > > > numbers in the basic type system is totally against
> > > > the abstraction purpose: consider the fact you should not have many chances to have an exactly fixed-with
> > > > integer like "i32" in the real business logic (expect for
> > > > some low-level [de]serialization works between some
> > > > on-wire formats and some in-memory representations), you're routinely making the conversion unconsciously
> > > > to fit the semantic gap between the code and the real design
> > > > implicitly. Such implicity is dangerous before
> > > > you leak "i32" to the design, and then you totally failed
> > > > to abstract details like "32" away. (Rust certainly
> > > > won't insert any check between the gap of "i32" and the_real_type_you_need_in_the_design!)
> > > >
> > > > And compared to exception handling, the typical error handling mechanism in Rust is somehow enforcing
> > > > the designers of API to go against separation of concerns, because the error information is always
> > > > forced explicitly (equally significantly to the non-error "workloads") in the type signature of
> > > > API (also often bad for ABI compatibility, but this is an implementation detail).
> > > >
> > > > Such glitches are often not obvious for most users, making it even more error-prone
> > > > in everyday programming. I don't expect my life easier working with these users.
> > >
> > > I agree here, but in the specific context of "everyday programming", Rust is not a good general purpose
> > > language, for the "everyday" when I just want to make something simple just works I want a GC and proper
> > > exception handling, C++ works better than Rust in this respect but C# works even better.
> > >
> > > Rust is claimed as "system programming" which is a very specific niche, it would be very ankward to use
> > > C# in this niche, C++ have some caveats too, but Rust do very well in this niche, since the topic started
> > > about Linux kernel, I don't think it would be very productive to ignore this specific detail.
> > >
> > I'm glad to see you agree with this, while some Rust fanboys still reject to face
> > the fact and routinely try to replace the use of other languages by Rust blindly.
> >
> > However, "everyday" for a professional programmer may mean he/she does the coding work everyday in a
> > period of the lifecycle of a project, so the restriction of the language applies day to day whatever
> > the domain is. Even in the context of system programming, lacking of the abstraction is not comfortable.
> > But with the limitation of the language, users may forget the reason and tend to compromise, which leads
> > to misinformation to newcomers. This is even occur in some written conventions. The Linux kernel coding
> > style 5) is a notable example. It says you should "NEVER EVER use a typedef unless you can clearly
> > match one of those rules", which is totally nonsense even in the kernel programming (analysis later).
> > I'm reluctant to get people who follow these dogmas without any doubts in my team.
> >
> >
> > Detail technical points about rule 5):
> >
> > i. Bullet 2. is redundant. The rule itself is not problematic,
> > but hiding of int v. long is not any more special
> > than other types. It is only outstanding to the limitation
> > oflanguages like C for historical reasons (in ISA
> > "native" types) which makes the meaning of types like "long" a mess. It is better to be an example.
> >
> > ii. Bullet c. is vague. What type-checking? Only by the C compiler? Or by any other means?
> >
> > If absolutely any nominal type checks (including manual
> > checks) are allowed, it just render 5) is useless.
> > Ironically, this is exact my position of the problem here: it is up to the designer, not the programmer.
> > If the designer of the components want to say "it is OK to have an nominal (opaque by design) type", it
> > should be here, whether such type is checkable in C. It is an implementation detail that specific language
> > like C cannot utilize this explicit intent to make the code better. (Well, there can be some headache to
> > check the occasional misuses of the type as a non-opaque one in C, but it deserves for C users more or
> > less.) Why bother such details in the convention in a coding style document? The decision of making the
> > type nominally opaque is totally out of the scope of the document, and irrelevant to C.
> >
> > This also renders bullet a. mostly nonsense in practice for the internal interface, because there is no
> > clear standpoint to define "totally" before you draft a standardized convention out of this document.
> >
> > Note the potential abuse is actually not a big deal in C than C++, at least with C
> > you have no chance to try something evil enough like "enable_if_t" to make
> > the not-enough-opaque type "T" made up of "typedef int T;" leaks everywhere.
> >
> > iii. Bullet d. is same to b., and it is even more specific to C. Not
> > saying it is wrong by itself, but combined with c., it is kidding.
> >
> > iv. Bullet e. is seriously wrong. It assumes the userspace having different disciplines to the
> > kernel space. Actually the need of type safety is no different between them, except the fact
> > in kernel you use C almost everywhere, so you must bear some compromised implementation of typechecking.
> > But ironically again, it is the decisions to rely on C makes the case worse: it is C allows
> > such case of lacking of type information to make the meaning of the code clearer (and more possibility
> > to be safer), and the rules in 5) even endorse the bad practice!
> >
> > v. The note in bullet a. is even more misleading. It seems to suggest opaque type is only
> > intend for portability, which is not true. As said, what to make a type nominal is up to
> > the designers, not necessarily to the programmers. The decision of what degrees of opaqueness
> > is also up to the designer's intent of the type. Yes, the "dichotomy" of opaqueness is wrong,
> > and partially opaque types have their own rights to live in the designs.
> >
> > Specifically, consider the hierarchy of standard conformance (like some concrete impl -> XSI ->
> > POSIX -> ISO C), you can't absolutely say something partially specialized in the middle is just
> > nonsense; in many cases, layering is actually an effective way to expose different conforming
> > requirements with few bloats. Such specifications may have partially opaque types to shape the
> > conforming requirements on types. Following the suggestion of bullet a., partially specialized
> > types must have accessors to pretend they are totally opaque in coding. This is absurd.
> >
> >
> > While I think the analysis is quite basic and obvious in the sense of computer science and engineering,
> > some people will not. Consider the fragmentation of int vs. size_t flame war brought by a few
> > notable "int fanboys" like Bjarne Stroustrup and Herb Sutter, as well as the status quo (int
> > is already polluted the design of the standard library, e.g. std::caught_exceptions), I don't
> > think making kernel people happy a necessary task. And as I believe such documentation is not
> > the root source of misinformation, I'm lazy to contribute to change it.
> >
>
> Long explanation, I think the rule is there because in C, pointers to type
> are not compatible even if they point to things which are compatible.
> In short, if someone use an "int" in a library but they typedef'ed it to my_int, and someone else use another
> "int" typedef'ed to their_int, you can use my_int in place of their_int, but not for pointers and you finish
> by adding so many casts from "my_int *" to "their_int *" and the software becomes unreadable.

Why would people stick in their own my_int? Especially if they always have to coerce to their_int? I'd have thought at worst in that case one would have an interface module that had the casts in.