dmcq (dmcq.delete@this.fano.co.uk) on July 18, 2021 4:00 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.
> >
>
> I'm turned off by talk of fanboys. I was not able to make much sense of what you said but I got the
> feeling your concerns were different from those of the developers of Linux. Their chief concern as
> far as those standards are concerned is to make the code easy to read and debug. If the compiler
> checks something then good, and a compiler can check types match. Putting in a struct rather than
> a typedef may take longer to write or occupy more space - but if the contents are relevant to code
> of at most two screens worth then they better be present in front of a debuggers eyes. And if somebody
> changes a struct then somebody updating the code ought to look at everywhere it is used rather than
> just being efficient in writing the code and inserting a line in an include file.

Plus by the way one has to be careful about depending on types at interfaces between systems. One can't just depend on the compiler conventions. For instance the ABI might say a byte is sent over with undefined top three bytes in a 32 bit register, or it might be signed. If the other side is compiled assuming the top is zero strange things can happen. So for an operating system it is better to make certain everything is defined even if that means not using types correctly semantically.