30 Jan
2023
30 Jan
'23
5:24 p.m.
I did not want to disrupt the FD 2 discussion, but I could not really let
this comment go unanswered:
"Smells like C++ to me. Rust in essence is a re-implementation of C++ not
C. It tries to pack as much features as it possibly can. "
It's hard for me to see how you can say this if you have done any work in
Rust and C++.
But, short form: Rust is not C++. Full stop.
I did not feel that comment should go unanswered, lest people believe it.
30 Jan
30 Jan
6:47 p.m.
On Monday, January 30, 2023, ron minnich <rminnich(a)gmail.com> wrote:
I did not want to disrupt the FD 2 discussion, but I
could not really let
this comment go unanswered:
"Smells like C++ to me. Rust in essence is a re-implementation of C++ not
C. It tries to pack as much features as it possibly can. "
It's hard for me to see how you can say this if you have done any work in
Rust and C++.
But, short form: Rust is not C++. Full stop.
I did not feel that comment should go unanswered, lest people believe it.
Well, I will stand by my opinion, but perhaps you misread what I meant. I
meant that as a whole Rust resembles more C++ than C. Technically it might
lie in between C and C++, but the amount of "features" certainly bring it
closer to C++. While it might be easier to write safer code in Rust than in
C++, I still think that its "weird" syntax and feature bloat make me
dislike it the way I dislike C++.
Just my .02. YMMV.
--Andy
6:59 p.m.
My understanding is it might "look and feel" more C++-ish than C, but what it is
doing under the hood for memory safety and such results in code much closer in candor to
C.
C++ relies on a pretty hefty stack of runtime for things that Rust takes care of much
earlier through concepts like ownership. The result is that things like memory safety are
handled by the compiler's analysis rather than libraries. Sure you may have more
modern-looking OOP constructs, but my understanding is those constructs are closer to
syntactic sugar than what most C++ environments do with constructing/destructing, passing
pointers, concurrency, etc.
Of course, I'm no expert so I'm just speaking from my own experiences with the
two languages, but my understanding is Rust is a C-ish systems language parading around in
fancy modern clothes, but it achieves most of its more sophisticated functionality at
compile time rather than relying on a bunch of runtime code to keep everything rolling.
I don't think Rust will "replace" C any time soon, just like C hasn't
really "replaced" FORTRAN and COBOL in a lot of places, but it will continue to
grow as a systems-programming language, especially what with the Linux kernel starting to
greenlight Rust components. Regardless, I personally see future value in Rust and so I
nabbed the book and am slowly learning it. Hopefully it isn't time wasted and we
start seeing more Rust-native interfaces out there. One of the main things holding me back
is a lack of native OpenGL interfacing. There are binding layers of course, but
that's just another stinky layer of code I don't control doing things I may or
may not agree with. As for writing my own bindings, I could do that...or I could just
write in C and be done with it :P
Who knows, as time goes on though, Rust may verge more and more into that territory of
"best of both worlds" with familiar OOP constructs for modern programmers and
similar performance to C where it counts. If nothing else, I can credit Rust as the first
new language I've actually bought the book for in a long, long time.
- Matt G.
------- Original Message -------
On Monday, January 30th, 2023 at 10:47 AM, Andy Kosela <akosela(a)andykosela.com>
wrote:
On Monday, January 30, 2023, ron minnich
<rminnich(a)gmail.com> wrote:
I did not want to disrupt the FD 2 discussion,
but I could not really let this comment go unanswered:
"Smells like C++ to me. Rust in essence is a re-implementation of C++ not C. It
tries to pack as much features as it possibly can. "
It's hard for me to see how you can say this if you have done any work in Rust and
C++.
But, short form: Rust is not C++. Full stop.
I did not feel that comment should go unanswered, lest people believe it.
Well, I will stand by my opinion, but perhaps you misread what I meant. I meant that as a
whole Rust resembles more C++ than C. Technically it might lie in between C and C++, but
the amount of "features" certainly bring it closer to C++. While it might be
easier to write safer code in Rust than in C++, I still think that its "weird"
syntax and feature bloat make me dislike it the way I dislike C++.
Just my .02. YMMV.
--Andy
7:35 p.m.
I don't know how many ways there are to say this, but Rust and C/C++ are
fundamentally different at the lowest level.
If you are just looking at Rust syntax in a superficial way, you might be
excused for thinking it's "C with features / C++ with differences."
But that's not how it is. It's like saying C is "just like assembly"
because labels have a ':' in them; or that Unix is "just like RSX"
because
they have vaguely similar commands.
Here's a real question that came up where I work: should the code shown
below be accepted (this is abstracted from a real example that is in use
... everywhere)?
We had one code analyzer that said, emphatically, NO; one person said YES,
another MAYBE. One piece of code, 3 answers :-)
char f() {
char *y;
g(&y);
return *y;
}
A specific question: should y be initialized to NULL?
The case to set y to NULL: otherwise it has an unknown value and it's
unsafe.
The case against setting y to NULL: it is pointless, as it slows the code
down slightly and g is going to change it anyway.
The case maybe: Why do you trust g() to always set it? Why don't you trust
g()? convince me.
You can't write this in Rust with this ambiguity. It won't compile. In
fact, & doesn't mean in Rust what it does in C.
Sorry to be such a pedant, but I was concerned that we not fall into the
"Rust is C++ all over again" trap.
As for replacing C, the velocity of Rust is just astonishing. I think folks
have been waiting for something to replace C for a long time, and Rust,
with all its headaches and issues, is likely to be that thing.
Personally, I still prefer Go, but I can also see which way the wind is
blowing, especially when I see Rust use exploding in firmware and user
mode, and now even in the Linux kernel.
On Mon, Jan 30, 2023 at 11:00 AM segaloco <segaloco(a)protonmail.com> wrote:
My understanding is it might "look and feel"
more C++-ish than C, but what
it is doing under the hood for memory safety and such results in code much
closer in candor to C.
C++ relies on a pretty hefty stack of runtime for things that Rust takes
care of much earlier through concepts like ownership. The result is that
things like memory safety are handled by the compiler's analysis rather
than libraries. Sure you may have more modern-looking OOP constructs, but
my understanding is those constructs are closer to syntactic sugar than
what most C++ environments do with constructing/destructing, passing
pointers, concurrency, etc.
Of course, I'm no expert so I'm just speaking from my own experiences with
the two languages, but my understanding is Rust is a C-ish systems language
parading around in fancy modern clothes, but it achieves most of its more
sophisticated functionality at compile time rather than relying on a bunch
of runtime code to keep everything rolling.
I don't think Rust will "replace" C any time soon, just like C
hasn't
really "replaced" FORTRAN and COBOL in a lot of places, but it will
continue to grow as a systems-programming language, especially what with
the Linux kernel starting to greenlight Rust components. Regardless, I
personally see future value in Rust and so I nabbed the book and am slowly
learning it. Hopefully it isn't time wasted and we start seeing more
Rust-native interfaces out there. One of the main things holding me back
is a lack of native OpenGL interfacing. There are binding layers of
course, but that's just another stinky layer of code I don't control doing
things I may or may not agree with. As for writing my own bindings, I
could do that...or I could just write in C and be done with it :P
Who knows, as time goes on though, Rust may verge more and more into that
territory of "best of both worlds" with familiar OOP constructs for modern
programmers *and* similar performance to C where it counts. If nothing
else, I can credit Rust as the first new language I've actually bought the
book for in a long, long time.
- Matt G.
------- Original Message -------
On Monday, January 30th, 2023 at 10:47 AM, Andy Kosela <
akosela(a)andykosela.com> wrote:
On Monday, January 30, 2023, ron minnich <rminnich(a)gmail.com> wrote:
I did not want to disrupt the FD 2 discussion,
but I could not really let
this comment go unanswered:
"Smells like C++ to me. Rust in essence is a re-implementation of C++ not
C. It tries to pack as much features as it possibly can. "
It's hard for me to see how you can say this if you have done any work in
Rust and C++.
But, short form: Rust is not C++. Full stop.
I did not feel that comment should go unanswered, lest people believe it.
Well, I will stand by my opinion, but perhaps you misread what I meant. I
meant that as a whole Rust resembles more C++ than C. Technically it might
lie in between C and C++, but the amount of "features" certainly bring it
closer to C++. While it might be easier to write safer code in Rust than in
C++, I still think that its "weird" syntax and feature bloat make me
dislike it the way I dislike C++.
Just my .02. YMMV.
--Andy
9:37 p.m.
On 2023-01-30 14:35, ron minnich wrote (in part):
As for replacing C, the velocity of Rust is just
astonishing. I think
folks have been waiting for something to replace C for a long time, and
Rust, with all its headaches and issues, is likely to be that thing.
Of possible interest:
https://devclass.com/2023/01/23/rust-has-no-formal-specification-and-it-is-…
N.
31 Jan
31 Jan
1:47 a.m.
Hello Ron,
On 1/30/23 20:35, ron minnich wrote:
I don't know how many ways there are to say this,
but Rust and C/C++ are
fundamentally different at the lowest level.
If you are just looking at Rust syntax in a superficial way, you might be
excused for thinking it's "C with features / C++ with differences."
But that's not how it is. It's like saying C is "just like assembly"
because
labels have a ':' in them; or that Unix is "just like RSX" because
they have
vaguely similar commands.
Here's a real question that came up where I work: should the code shown below be
accepted (this is abstracted from a real example that is in use ... everywhere)?
We had one code analyzer that said, emphatically, NO; one person said YES,
another MAYBE. One piece of code, 3 answers :-)
char f() {
char *y;
g(&y);
return *y;
}
A specific question: should y be initialized to NULL?
No. At least not if you don't want to use the value NULL in your program.
Using NULL as something to avoid Undefined Behavior is wrong, and it will
contribute to hide programmer errors.
These days, compilers and static analyzers are smart enough to detect
uninitialized variables, even across Translation Units, and throw an error,
letting the programmer fix such bugs, when they occur.
The practice of initializing always to NULL and 0 provides no value, and
silences all of those warnings, thus creating silent bugs, that will bite some
cold winter night.
I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't
initialize variables and especially pointers (well, you need to enable the
warning that does that, but it can warn). That warning is there due to some
coding style or certifications that require it. I recommend disabling those
bogus warnings, and forgetting about the bogus coding style or certification
that requires you to write bogus code.
The case to set y to NULL: otherwise it has an
unknown value and it's unsafe.
Is an undefined value less safe than an unexpected one? I don't think so. At
least compilers can detect the former, but not the latter.
The case against setting y to NULL: it is pointless,
as it slows the code down
slightly and g is going to change it anyway.
Performance is a very minor thing. But it's a nice side-effect that doing the
right thing has performance advantages. Readability is a good reason (and in
fact, the compiler suffers that readability too, which is the cause of the
silencing of the wanted warnings.
The case maybe: Why do you trust g() to always set it?
Why don't you trust g()?
convince me.
Well, it depends on the contract of g(). If the contract is that it may not
initialize the variable, then sure, initialize it yourself, or even better,
check for g()'s errors, and react when it fails and doesn't initialize it.
If the contract is that it should always initialize it, then trust it blindly.
The compiler will tell you when it doesn't happen (that is, when g() has a bug).
You can't write this in Rust with this ambiguity. It won't compile. In fact,
&
doesn't mean in Rust what it does in C.
I don't know Rust. Does it force NULL initialization? If so, I guess it's a
bad design choice. Unless Rust is so different that it can detect such
programmer errors even having defined default initialization, but I can't
imagine how that is.
Sorry to be such a pedant, but I was concerned that we not fall into the "Rust
is C++ all over again" trap.
As for replacing C, the velocity of Rust is just astonishing. I think folks have
been waiting for something to replace C for a long time, and Rust, with all its
headaches and issues, is likely to be that thing.
Modern C is receiving a lot of improvements from C++ and other languages. It's
getting really good in fixing the small issues it had in the past (and GNU C
provides even more good things). GNU C2x is quite safe and readable, compared
to say ISO C99 versions.
I don't think C will ever be replaced. And I hope it doesn't.
Possibly, something like with Plan9 and Unix/Linux will happen. The good things
from other languages will come back in one form or another to C. The
not-so-good ones will be discarded.
Personally, I still prefer Go, but I can also see which way the wind is blowing,
especially when I see Rust use exploding in firmware and user mode, and now even
in the Linux kernel.
Cheers,
Alex
2:55 a.m.
On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
<alx.manpages(a)gmail.com> wrote:
The number of situations where the compiler can't tell whether `g` has
a bug is unbounded.
Rust enforces that all variables must be initialized prior to use.
Whether they're initialized with a zero value or something else is up
to the programmer; but not initializing is a compile-time error.
For example:
| fn main() {
| let x;
| if thing_is_true() {
| x = 5;
| } else {
| x = 3;
| }
| println!("x={x}");
| }
In fact, this is good; this allows us to employ a technique called,
"Type-Driven Development", whereby we can create some type that
encodes an invariant about the object. An object of that type is
written in such a way that once it has been initialized, the mere
existence of the object is sufficient to prove that the invariant
holds, and need not be retested whenever the object is used. For
example:
| #[repr(transparent)]
| struct PageFrameAddr(u64);
| impl PageFrameAddr {
| fn new_round_down(addr: u64) -> PageFrameAddr {
| PageFrameAddr(addr & !0xFFF)
| }
| }
Here, "PageFrameAddr" contains a 4KiB-aligned page address. Since the
only way to create one of these is by the, `new_round_down` associated
method that masks off the low bits, we can be sure that if we get one
of these, the contained address is properly aligned. In C, we'd
pretty much have to test at the site of use.
This is an extremely powerful technique; cf Alexis King's blog post,
"Parse Don't Validate"
(https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)
and Cliff Biffle's talk on the Hubris embedded RTOS
(https://talks.osfc.io/osfc2021/talk/JTWYEH/).
C23 looks like it will be a better language that C11, but I don't know
that even JeanHeyd would suggest it's "quite safe". :-/
- Dan C.
Hello Ron,
On 1/30/23 20:35, ron minnich wrote:
Sorry, I think this misses the point: how do you meaningfully tell
that `g` did something to `y` so that it's safe to indirect in the
`return`?
On the other hand, one could write,
char f() {
char *y = NULL;
g(&y);
if (y == NULL)
panic("g failed");
return *y;
}
C, of course, can't tell in the original. And while you can now tell
that `g` did _something_ to `y`, you still really don't know that `y`
points to something valid.
I don't know how many ways there are to say
this, but Rust and C/C++ are
fundamentally different at the lowest level.
If you are just looking at Rust syntax in a superficial way, you might be
excused for thinking it's "C with features / C++ with differences."
But that's not how it is. It's like saying C is "just like assembly"
because
labels have a ':' in them; or that Unix is "just like RSX" because
they have
vaguely similar commands.
Here's a real question that came up where I work: should the code shown below be
accepted (this is abstracted from a real example that is in use ... everywhere)?
We had one code analyzer that said, emphatically, NO; one person said YES,
another MAYBE. One piece of code, 3 answers :-)
char f() {
char *y;
g(&y);
return *y;
}
A specific question: should y be initialized to NULL?
No. At least not if you don't want to use the value NULL in your program.
Using NULL as something to avoid Undefined Behavior is wrong, and it will
contribute to hide programmer errors. These days, compilers and static analyzers are smart
enough to detect
uninitialized variables, even across Translation Units, and throw an error,
letting the programmer fix such bugs, when they occur.
In many cases, yes, but not in all. That would be equivalent to
solving the halting problem.
The practice of initializing always to NULL and 0
provides no value, and
silences all of those warnings, thus creating silent bugs, that will bite some
cold winter night.
I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't
initialize variables and especially pointers (well, you need to enable the
warning that does that, but it can warn). That warning is there due to some
coding style or certifications that require it. I recommend disabling those
bogus warnings, and forgetting about the bogus coding style or certification
that requires you to write bogus code.
Oh my.
The case to
set y to NULL: otherwise it has an unknown value and it's unsafe.
Is an undefined value less safe than an unexpected one? I don't think so. At
least compilers can detect the former, but not the latter.
The case against setting y to NULL: it is
pointless, as it slows the code down
slightly and g is going to change it anyway.
Performance is a very minor thing. But it's a nice side-effect that doing the
right thing has performance advantages. Readability is a good reason (and in
fact, the compiler suffers that readability too, which is the cause of the
silencing of the wanted warnings.
The case maybe: Why do you trust g() to always
set it? Why don't you trust g()?
convince me.
Well, it depends on the contract of g(). If the contract is that it may not
initialize the variable, then sure, initialize it yourself, or even better,
check for g()'s errors, and react when it fails and doesn't initialize it.
If the contract is that it should always initialize it, then trust it blindly.
The compiler will tell you when it doesn't happen (that is, when g() has a bug).
You can't
write this in Rust with this ambiguity. It won't compile. In fact, &
doesn't mean in Rust what it does in C.
I don't know Rust. Does it force NULL initialization? If so, I guess it's a
bad design choice. Unless Rust is so different that it can detect such
programmer errors even having defined default initialization, but I can't
imagine how that is. Sorry to be
such a pedant, but I was concerned that we not fall into the "Rust
is C++ all over again" trap.
As for replacing C, the velocity of Rust is just astonishing. I think folks have
been waiting for something to replace C for a long time, and Rust, with all its
headaches and issues, is likely to be that thing.
Modern C is receiving a lot of improvements from C++ and other languages. It's
getting really good in fixing the small issues it had in the past (and GNU C
provides even more good things). GNU C2x is quite safe and readable, compared
to say ISO C99 versions. I don't think C will ever be replaced. And I
hope it doesn't.
Possibly, something like with Plan9 and Unix/Linux will happen. The good things
from other languages will come back in one form or another to C. The
not-so-good ones will be discarded.
Personally, I still prefer Go, but I can also see which way the wind is blowing,
especially when I see Rust use exploding in firmware and user mode, and now even
in the Linux kernel.
Cheers,
Alex
3:59 a.m.
That example was a simplified bit of code from a widely used code base. All
I need to do is change the function g go a pointer to function, or have it
be provided by a .so, and all bets are off.
In any event, the important thing here is not that y should be initialized,
or should not; it's that it is not possible to get a consistent answer on
the question, from people who have been writing in C for decades.
ron
On Mon, Jan 30, 2023 at 6:56 PM Dan Cross <crossd(a)gmail.com> wrote:
On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
<alx.manpages(a)gmail.com> wrote:
program.
doing
the
not
it's a
languages.
It's
Hello Ron,
On 1/30/23 20:35, ron minnich wrote:
> I don't know how many ways there are to say this, but Rust and C/C++
are
> fundamentally different at the lowest
level.
>
> If you are just looking at Rust syntax in a superficial way, you might
be
> excused for thinking it's "C with
features / C++ with differences."
>
> But that's not how it is. It's like saying C is "just like
assembly"
because
> labels have a ':' in them; or that
Unix is "just like RSX" because
they have
> vaguely similar commands.
>
> Here's a real question that came up where I work: should the code
shown
below be
> accepted (this is abstracted from a real
example that is in use ...
everywhere)?
> We had one code analyzer that said,
emphatically, NO; one person said
YES,
another
MAYBE. One piece of code, 3 answers :-)
char f() {
char *y;
g(&y);
return *y;
}
A specific question: should y be initialized to NULL?
No. At least not if you don't want to use the value NULL in your Using NULL as something to avoid Undefined
Behavior is wrong, and it will
contribute to hide programmer errors.
Sorry, I think this misses the point: how do you meaningfully tell
that `g` did something to `y` so that it's safe to indirect in the
`return`?
On the other hand, one could write,
char f() {
char *y = NULL;
g(&y);
if (y == NULL)
panic("g failed");
return *y;
}
C, of course, can't tell in the original. And while you can now tell
that `g` did _something_ to `y`, you still really don't know that `y`
points to something valid.
These days, compilers and static analyzers are
smart enough to detect
uninitialized variables, even across Translation Units, and throw an
error,
letting the programmer fix such bugs, when they
occur.
In many cases, yes, but not in all. That would be equivalent to
solving the halting problem.
The practice of initializing always to NULL and 0
provides no value, and
silences all of those warnings, thus creating silent bugs, that will
bite some
cold winter night.
I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't
initialize variables and especially pointers (well, you need to enable
the
warning that does that, but it can warn). That
warning is there due to
some
coding style or certifications that require it.
I recommend disabling
those
bogus warnings, and forgetting about the bogus
coding style or
certification
that requires you to write bogus code.
Oh my.
> The case to set y to NULL: otherwise it has
an unknown value and it's
unsafe.
Is an undefined value less safe than an unexpected one? I don't think
so.
At
least compilers can detect the former, but not
the latter.
> The case against setting y to NULL: it is pointless, as it slows the
code
down
slightly
and g is going to change it anyway.
Performance is a very minor thing. But it's a nice side-effect that right thing has performance advantages.
Readability is a good reason
(and in
fact, the compiler suffers that readability too,
which is the cause of
the
silencing of the wanted warnings.
> The case maybe: Why do you trust g() to always set it? Why don't you
trust g()?
convince
me.
Well, it depends on the contract of g(). If the contract is that it may initialize the variable, then sure, initialize it
yourself, or even
better,
check for g()'s errors, and react when it
fails and doesn't initialize
it.
If the contract is that it should always initialize it, then trust it
blindly.
The compiler will tell you when it doesn't
happen (that is, when g() has
a bug).
The number of situations where the compiler can't tell whether `g` has
a bug is unbounded.
> You can't write this in Rust with this
ambiguity. It won't compile. In
fact, &
doesn't mean in Rust what it does in C.
I don't know Rust. Does it force NULL initialization? If so, I guess bad design choice. Unless Rust is so different
that it can detect such
programmer errors even having defined default initialization, but I can't
imagine how that is.
Rust enforces that all variables must be initialized prior to use.
Whether they're initialized with a zero value or something else is up
to the programmer; but not initializing is a compile-time error.
For example:
| fn main() {
| let x;
| if thing_is_true() {
| x = 5;
| } else {
| x = 3;
| }
| println!("x={x}");
| }
In fact, this is good; this allows us to employ a technique called,
"Type-Driven Development", whereby we can create some type that
encodes an invariant about the object. An object of that type is
written in such a way that once it has been initialized, the mere
existence of the object is sufficient to prove that the invariant
holds, and need not be retested whenever the object is used. For
example:
| #[repr(transparent)]
| struct PageFrameAddr(u64);
| impl PageFrameAddr {
| fn new_round_down(addr: u64) -> PageFrameAddr {
| PageFrameAddr(addr & !0xFFF)
| }
| }
Here, "PageFrameAddr" contains a 4KiB-aligned page address. Since the
only way to create one of these is by the, `new_round_down` associated
method that masks off the low bits, we can be sure that if we get one
of these, the contained address is properly aligned. In C, we'd
pretty much have to test at the site of use.
This is an extremely powerful technique; cf Alexis King's blog post,
"Parse Don't Validate"
(https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)
and Cliff Biffle's talk on the Hubris embedded RTOS
(https://talks.osfc.io/osfc2021/talk/JTWYEH/).
> Sorry to be such a pedant, but I was
concerned that we not fall into
the "Rust
> is C++ all over again" trap.
>
> As for replacing C, the velocity of Rust is just astonishing. I think
folks
have
> been waiting for something to replace C for
a long time, and Rust,
with all its
headaches
and issues, is likely to be that thing.
Modern C is receiving a lot of improvements from C++ and other getting really good in fixing the small issues it
had in the past (and
GNU C
provides even more good things). GNU C2x is
quite safe and readable,
compared
to say ISO C99 versions.
C23 looks like it will be a better language that C11, but I don't know
that even JeanHeyd would suggest it's "quite safe". :-/
- Dan C.
I don't think C will ever be replaced. And
I hope it doesn't.
Possibly, something like with Plan9 and Unix/Linux will happen. The
good things
from other languages will come back in one form
or another to C. The
not-so-good ones will be discarded.
>
> Personally, I still prefer Go, but I can also see which way the wind
is
blowing,
> especially when I see Rust use exploding in
firmware and user mode,
and now even
in the
Linux kernel.
Cheers,
Alex
12:26 p.m.
On Mon, Jan 30, 2023 at 10:59 PM ron minnich <rminnich(a)gmail.com> wrote:
That example was a simplified bit of code from a
widely used code base. All I need to do is change the function g go a pointer to function,
or have it be provided by a .so, and all bets are off.
In any event, the important thing here is not that y should be initialized, or should
not; it's that it is not possible to get a consistent answer on the question, from
people who have been writing in C for decades.
Indeed, I was agreeing with you, Ron. :-)
- Dan C.
On Mon, Jan 30, 2023 at 6:56 PM Dan Cross
<crossd(a)gmail.com> wrote:
>
> On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
> <alx.manpages(a)gmail.com> wrote:
> > Hello Ron,
> >
> > On 1/30/23 20:35, ron minnich wrote:
> > > I don't know how many ways there are to say this, but Rust and C/C++
are
> > > fundamentally different at the lowest level.
> > >
> > > If you are just looking at Rust syntax in a superficial way, you might be
> > > excused for thinking it's "C with features / C++ with
differences."
> > >
> > > But that's not how it is. It's like saying C is "just like
assembly" because
> > > labels have a ':' in them; or that Unix is "just like
RSX" because they have
> > > vaguely similar commands.
> > >
> > > Here's a real question that came up where I work: should the code
shown below be
> > > accepted (this is abstracted from a real example that is in use ...
everywhere)?
> > > We had one code analyzer that said, emphatically, NO; one person said YES,
> > > another MAYBE. One piece of code, 3 answers :-)
> > >
> > > char f() {
> > > char *y;
> > > g(&y);
> > > return *y;
> > > }
> > >
> > >
> > > A specific question: should y be initialized to NULL?
> >
> > No. At least not if you don't want to use the value NULL in your program.
> > Using NULL as something to avoid Undefined Behavior is wrong, and it will
> > contribute to hide programmer errors.
>
> Sorry, I think this misses the point: how do you meaningfully tell
> that `g` did something to `y` so that it's safe to indirect in the
> `return`?
>
> On the other hand, one could write,
>
> char f() {
> char *y = NULL;
> g(&y);
> if (y == NULL)
> panic("g failed");
> return *y;
> }
>
> C, of course, can't tell in the original. And while you can now tell
> that `g` did _something_ to `y`, you still really don't know that `y`
> points to something valid.
>
> > These days, compilers and static analyzers are smart enough to detect
> > uninitialized variables, even across Translation Units, and throw an error,
> > letting the programmer fix such bugs, when they occur.
>
> In many cases, yes, but not in all. That would be equivalent to
> solving the halting problem.
>
> > The practice of initializing always to NULL and 0 provides no value, and
> > silences all of those warnings, thus creating silent bugs, that will bite some
> > cold winter night.
> >
> > I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't
> > initialize variables and especially pointers (well, you need to enable the
> > warning that does that, but it can warn). That warning is there due to some
> > coding style or certifications that require it. I recommend disabling those
> > bogus warnings, and forgetting about the bogus coding style or certification
> > that requires you to write bogus code.
>
> Oh my.
>
> > > The case to set y to NULL: otherwise it has an unknown value and it's
unsafe.
> >
> > Is an undefined value less safe than an unexpected one? I don't think so.
At
> > least compilers can detect the former, but not the latter.
> >
> > > The case against setting y to NULL: it is pointless, as it slows the code
down
> > > slightly and g is going to change it anyway.
> >
> > Performance is a very minor thing. But it's a nice side-effect that doing
the
> > right thing has performance advantages. Readability is a good reason (and in
> > fact, the compiler suffers that readability too, which is the cause of the
> > silencing of the wanted warnings.
> >
> > > The case maybe: Why do you trust g() to always set it? Why don't you
trust g()?
> > > convince me.
> >
> > Well, it depends on the contract of g(). If the contract is that it may not
> > initialize the variable, then sure, initialize it yourself, or even better,
> > check for g()'s errors, and react when it fails and doesn't initialize
it.
> >
> > If the contract is that it should always initialize it, then trust it blindly.
> > The compiler will tell you when it doesn't happen (that is, when g() has a
bug).
>
> The number of situations where the compiler can't tell whether `g` has
> a bug is unbounded.
>
> > > You can't write this in Rust with this ambiguity. It won't
compile. In fact, &
> > > doesn't mean in Rust what it does in C.
> >
> > I don't know Rust. Does it force NULL initialization? If so, I guess
it's a
> > bad design choice. Unless Rust is so different that it can detect such
> > programmer errors even having defined default initialization, but I can't
> > imagine how that is.
>
> Rust enforces that all variables must be initialized prior to use.
> Whether they're initialized with a zero value or something else is up
> to the programmer; but not initializing is a compile-time error.
>
> For example:
>
> | fn main() {
> | let x;
> | if thing_is_true() {
> | x = 5;
> | } else {
> | x = 3;
> | }
> | println!("x={x}");
> | }
>
> In fact, this is good; this allows us to employ a technique called,
> "Type-Driven Development", whereby we can create some type that
> encodes an invariant about the object. An object of that type is
> written in such a way that once it has been initialized, the mere
> existence of the object is sufficient to prove that the invariant
> holds, and need not be retested whenever the object is used. For
> example:
>
> | #[repr(transparent)]
> | struct PageFrameAddr(u64);
> | impl PageFrameAddr {
> | fn new_round_down(addr: u64) -> PageFrameAddr {
> | PageFrameAddr(addr & !0xFFF)
> | }
> | }
>
> Here, "PageFrameAddr" contains a 4KiB-aligned page address. Since the
> only way to create one of these is by the, `new_round_down` associated
> method that masks off the low bits, we can be sure that if we get one
> of these, the contained address is properly aligned. In C, we'd
> pretty much have to test at the site of use.
>
> This is an extremely powerful technique; cf Alexis King's blog post,
> "Parse Don't Validate"
> (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)
> and Cliff Biffle's talk on the Hubris embedded RTOS
> (https://talks.osfc.io/osfc2021/talk/JTWYEH/).
>
> > > Sorry to be such a pedant, but I was concerned that we not fall into the
"Rust
> > > is C++ all over again" trap.
> > >
> > > As for replacing C, the velocity of Rust is just astonishing. I think folks
have
> > > been waiting for something to replace C for a long time, and Rust, with all
its
> > > headaches and issues, is likely to be that thing.
> >
> > Modern C is receiving a lot of improvements from C++ and other languages.
It's
> > getting really good in fixing the small issues it had in the past (and GNU C
> > provides even more good things). GNU C2x is quite safe and readable, compared
> > to say ISO C99 versions.
>
> C23 looks like it will be a better language that C11, but I don't know
> that even JeanHeyd would suggest it's "quite safe". :-/
>
> - Dan C.
>
>
> > I don't think C will ever be replaced. And I hope it doesn't.
> >
> > Possibly, something like with Plan9 and Unix/Linux will happen. The good
things
> > from other languages will come back in one form or another to C. The
> > not-so-good ones will be discarded.
> >
> > >
> > > Personally, I still prefer Go, but I can also see which way the wind is
blowing,
> > > especially when I see Rust use exploding in firmware and user mode, and now
even
> > > in the Linux kernel.
> >
> > Cheers,
> >
> > Alex
2:15 p.m.
Although few will admit when their uneducated opinion is wrong, it is true
that Rust and C++ are very different. They are as different as any two
clearly different languages are. Their respective feature sets are quite
different and do not overlap any more than any two totally different
languages do.
Blake McBride
On Mon, Jan 30, 2023 at 11:26 AM ron minnich <rminnich(a)gmail.com> wrote:
I did not want to disrupt the FD 2 discussion, but I
could not really let
this comment go unanswered:
"Smells like C++ to me. Rust in essence is a re-implementation of C++ not
C. It tries to pack as much features as it possibly can. "
It's hard for me to see how you can say this if you have done any work in
Rust and C++.
But, short form: Rust is not C++. Full stop.
I did not feel that comment should go unanswered, lest people believe it.
1 Feb
1 Feb
12:40 a.m.
ron minnich wrote in
<CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ(a)mail.gmail.com>om>:
|That example was a simplified bit of code from a widely used code base. All
|I need to do is change the function g go a pointer to function, or have it
|be provided by a .so, and all bets are off.
|
|In any event, the important thing here is not that y should be initialized,
|or should not; it's that it is not possible to get a consistent answer on
|the question, from people who have been writing in C for decades.
I find the syntax just terrible. (I have not programmed with it.)
I mean annotations are for the better, ok, (but i luckily get away
with only "const" and "volatile" (and "mutable"), and leave
things
like "restrict" be a good man). Johannes Lundberg i think it was
who then left FreeBSD (?) but pointing to a Rust program
he had written (i cannot find the reference), that was a few years
ago (i looked once i composed this message first, it might even
had been as early as 2017!), and i was lucky i do not have to deal
with it.
Even nim-lang.org that at least converted its code to plain C back
in the day when it was still called Nimrod is too heavy for me now,
but claims to be hard realtime aware etc. It at least tries to
give programmers some syntactic sugar that makes people happy when
they look at the screen for 7 hours (underpaid) or 16 hours
(over-ambitioned). Like the only python thing i like, the
syntax sugar. But as languages grow they get more and more
"refined", and now i read things like
type
BinaryTree*[T] = ref object # BinaryTree is a generic type with
# generic param `T`
le, ri: BinaryTree[T] # left and right subtrees; may be nil
data: T # the data stored in a node
proc newNode*[T](data: T): BinaryTree[T] =
# constructor for a node
new(result)
result.data = data
which gets me off a bit and makes me think that "hey, maybe
Objective-C is not really the worst thing" (despite the syntax).
I do not know. Everything beyond a small monolithic
self-contained thing is a problem per se. You can then unit test
atomically, and if thousands of modules do that, you plug them to
a better whole. But that also not a good answer, all those flakes
that live their own life, many maybe even in remote locations out
of any control.
You could have a language which hard fixates all the call chain,
or you could have tools which bring this to a small and simple
language which does not offer it. A compiler can figure out which
variables are assigned etc and could create in-object-file
annotations which the linker automatically verifies.
Of course there are many code paths through functions.
Back in 2009 when i bought the one Apple i wanted to have i tried
out their Development software, which i think required internet
access. All the pop-ups and titles, i think it (later?) could
compile on-the-fly and inject the new object in the running tested
application, etc.
And then there are semantic description languages like interface
builders, where robots create the actual code. So then you could
have Corba interface descriptions / DBUS and plug it all via it.
Then Rob Pike says "make it a string" (more or less), and luckily
i do not have dyslexia.
Maybe Qt has a good answer by not only not banishing the
C preprocessor, but introducing another one on top.
So then the compiler can analyze the code and generate a correct
variable-state-at-function-call-time state that a dynamic linker
could then verify against the consumer or producer (whatever is
needed) of linked modules, that link modules, that link modules,
all of which are subject to replacements due to development
iterations, bug patches etc, ie, new releases.
As in, the library versioning that is used for ELF object files,
today often even linker scripts which furtherly diversify this,
offer are not enough, they do not do this. They only bundle
a name to a library version, or multiple (as in
1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3
33 FUNC GLOBAL DEFAULT 13 realpath(a)GLIBC_2.2.5)
I do not know how Rust deals with this. Is it at all possible to
fixate all the call chain over all possibly involved dynamics?
What do i gain from initializing an object with a default value if
that default value is not not not not one of the values that
i expect after some external function is called?
Sure i not rarely see patches fly by where one more memset(,0,) is
used to fully initialize a struct / prevent memory address
disclosures (i only track BSDs).
And there are still patches that fix bugs on old code that
sometimes is twenty years or more, say zlib or tzcode.
And then there are compiler bugs that bring in bugs -- that is not
avoidable, even if the documentation is clear and obvious like
/* The application can compare zlibVersion and ZLIB_VERSION for consistency.
If the first character differs, the library code actually used is not
compatible with the zlib.h header file used by the application. This check
is automatically made by deflateInit and inflateInit.
*/
That is only graspable by a human programmer that reads it. Rapid
application development that surely is not.
(And actually i am not sure this is really true. But i personally
would hope for it. It is more earthy, and has more blood, sweat
and tears.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
12:49 a.m.
Even though I participated in this thread, so I too have sinned, this
definitely wants to be discussed elsewhere. comp.lang.c maybe?
This discussion reminds a lot of what my career has been like. Over and
over again, I got told "that won't work". I wasn't very interested
in
those people, if they stayed out of my way. I was way more interested
in the people who said "hmm, maybe if you did it this way".
I've written a ton of working C code. I've managed and guided others
to do the same. I'm positive that I've written way more commercially
supported C code than was present in v6/v7 kernels. Not sure about
userspace, I think Unix has me beat there.
The point? It's very possible to write working C code. You need good
programmers and those seem to be going out of style so people are turning
to Rust because it doesn't compile crappy code.
I'm just happy to be retired, C worked for me for 40+ years, I feel
like I dodged a learning curve bullet by getting out before I had to
switch to Rust (or whatever).
On Wed, Feb 01, 2023 at 01:40:23AM +0100, Steffen Nurpmeso wrote:
ron minnich wrote in
<CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ(a)mail.gmail.com>om>:
|That example was a simplified bit of code from a widely used code base. All
|I need to do is change the function g go a pointer to function, or have it
|be provided by a .so, and all bets are off.
|
|In any event, the important thing here is not that y should be initialized,
|or should not; it's that it is not possible to get a consistent answer on
|the question, from people who have been writing in C for decades.
I find the syntax just terrible. (I have not programmed with it.)
I mean annotations are for the better, ok, (but i luckily get away
with only "const" and "volatile" (and "mutable"), and leave
things
like "restrict" be a good man). Johannes Lundberg i think it was
who then left FreeBSD (?) but pointing to a Rust program
he had written (i cannot find the reference), that was a few years
ago (i looked once i composed this message first, it might even
had been as early as 2017!), and i was lucky i do not have to deal
with it.
Even nim-lang.org that at least converted its code to plain C back
in the day when it was still called Nimrod is too heavy for me now,
but claims to be hard realtime aware etc. It at least tries to
give programmers some syntactic sugar that makes people happy when
they look at the screen for 7 hours (underpaid) or 16 hours
(over-ambitioned). Like the only python thing i like, the
syntax sugar. But as languages grow they get more and more
"refined", and now i read things like
type
BinaryTree*[T] = ref object # BinaryTree is a generic type with
# generic param `T`
le, ri: BinaryTree[T] # left and right subtrees; may be nil
data: T # the data stored in a node
proc newNode*[T](data: T): BinaryTree[T] =
# constructor for a node
new(result)
result.data = data
which gets me off a bit and makes me think that "hey, maybe
Objective-C is not really the worst thing" (despite the syntax).
I do not know. Everything beyond a small monolithic
self-contained thing is a problem per se. You can then unit test
atomically, and if thousands of modules do that, you plug them to
a better whole. But that also not a good answer, all those flakes
that live their own life, many maybe even in remote locations out
of any control.
You could have a language which hard fixates all the call chain,
or you could have tools which bring this to a small and simple
language which does not offer it. A compiler can figure out which
variables are assigned etc and could create in-object-file
annotations which the linker automatically verifies.
Of course there are many code paths through functions.
Back in 2009 when i bought the one Apple i wanted to have i tried
out their Development software, which i think required internet
access. All the pop-ups and titles, i think it (later?) could
compile on-the-fly and inject the new object in the running tested
application, etc.
And then there are semantic description languages like interface
builders, where robots create the actual code. So then you could
have Corba interface descriptions / DBUS and plug it all via it.
Then Rob Pike says "make it a string" (more or less), and luckily
i do not have dyslexia.
Maybe Qt has a good answer by not only not banishing the
C preprocessor, but introducing another one on top.
So then the compiler can analyze the code and generate a correct
variable-state-at-function-call-time state that a dynamic linker
could then verify against the consumer or producer (whatever is
needed) of linked modules, that link modules, that link modules,
all of which are subject to replacements due to development
iterations, bug patches etc, ie, new releases.
As in, the library versioning that is used for ELF object files,
today often even linker scripts which furtherly diversify this,
offer are not enough, they do not do this. They only bundle
a name to a library version, or multiple (as in
1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3
33 FUNC GLOBAL DEFAULT 13 realpath(a)GLIBC_2.2.5)
I do not know how Rust deals with this. Is it at all possible to
fixate all the call chain over all possibly involved dynamics?
What do i gain from initializing an object with a default value if
that default value is not not not not one of the values that
i expect after some external function is called?
Sure i not rarely see patches fly by where one more memset(,0,) is
used to fully initialize a struct / prevent memory address
disclosures (i only track BSDs).
And there are still patches that fix bugs on old code that
sometimes is twenty years or more, say zlib or tzcode.
And then there are compiler bugs that bring in bugs -- that is not
avoidable, even if the documentation is clear and obvious like
/* The application can compare zlibVersion and ZLIB_VERSION for consistency.
If the first character differs, the library code actually used is not
compatible with the zlib.h header file used by the application. This check
is automatically made by deflateInit and inflateInit.
*/
That is only graspable by a human programmer that reads it. Rapid
application development that surely is not.
(And actually i am not sure this is really true. But i personally
would hope for it. It is more earthy, and has more blood, sweat
and tears.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
12:50 a.m.
New subject: Algol rules: was something about Rust is not C++
Well, I just read this as Rust is dead... here's hoping, but seriously,
if we're gonna go off and have a language vs language discussion, I
personally don't think we've had any real language innovation since
Algol 60, well maybe lisp... sheesh, surely we're in COFF territory.
On 1/31/23 6:40 PM, Steffen Nurpmeso wrote:
ron minnich wrote in
<CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ(a)mail.gmail.com>om>:
|That example was a simplified bit of code from a widely used code base. All
|I need to do is change the function g go a pointer to function, or have it
|be provided by a .so, and all bets are off.
|
|In any event, the important thing here is not that y should be initialized,
|or should not; it's that it is not possible to get a consistent answer on
|the question, from people who have been writing in C for decades.
I find the syntax just terrible. (I have not programmed with it.)
I mean annotations are for the better, ok, (but i luckily get away
with only "const" and "volatile" (and "mutable"), and leave
things
like "restrict" be a good man). Johannes Lundberg i think it was
who then left FreeBSD (?) but pointing to a Rust program
he had written (i cannot find the reference), that was a few years
ago (i looked once i composed this message first, it might even
had been as early as 2017!), and i was lucky i do not have to deal
with it.
Even nim-lang.org that at least converted its code to plain C back
in the day when it was still called Nimrod is too heavy for me now,
but claims to be hard realtime aware etc. It at least tries to
give programmers some syntactic sugar that makes people happy when
they look at the screen for 7 hours (underpaid) or 16 hours
(over-ambitioned). Like the only python thing i like, the
syntax sugar. But as languages grow they get more and more
"refined", and now i read things like
type
BinaryTree*[T] = ref object # BinaryTree is a generic type with
# generic param `T`
le, ri: BinaryTree[T] # left and right subtrees; may be nil
data: T # the data stored in a node
proc newNode*[T](data: T): BinaryTree[T] =
# constructor for a node
new(result)
result.data = data
which gets me off a bit and makes me think that "hey, maybe
Objective-C is not really the worst thing" (despite the syntax).
I do not know. Everything beyond a small monolithic
self-contained thing is a problem per se. You can then unit test
atomically, and if thousands of modules do that, you plug them to
a better whole. But that also not a good answer, all those flakes
that live their own life, many maybe even in remote locations out
of any control.
You could have a language which hard fixates all the call chain,
or you could have tools which bring this to a small and simple
language which does not offer it. A compiler can figure out which
variables are assigned etc and could create in-object-file
annotations which the linker automatically verifies.
Of course there are many code paths through functions.
Back in 2009 when i bought the one Apple i wanted to have i tried
out their Development software, which i think required internet
access. All the pop-ups and titles, i think it (later?) could
compile on-the-fly and inject the new object in the running tested
application, etc.
And then there are semantic description languages like interface
builders, where robots create the actual code. So then you could
have Corba interface descriptions / DBUS and plug it all via it.
Then Rob Pike says "make it a string" (more or less), and luckily
i do not have dyslexia.
Maybe Qt has a good answer by not only not banishing the
C preprocessor, but introducing another one on top.
So then the compiler can analyze the code and generate a correct
variable-state-at-function-call-time state that a dynamic linker
could then verify against the consumer or producer (whatever is
needed) of linked modules, that link modules, that link modules,
all of which are subject to replacements due to development
iterations, bug patches etc, ie, new releases.
As in, the library versioning that is used for ELF object files,
today often even linker scripts which furtherly diversify this,
offer are not enough, they do not do this. They only bundle
a name to a library version, or multiple (as in
1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3
33 FUNC GLOBAL DEFAULT 13 realpath(a)GLIBC_2.2.5)
I do not know how Rust deals with this. Is it at all possible to
fixate all the call chain over all possibly involved dynamics?
What do i gain from initializing an object with a default value if
that default value is not not not not one of the values that
i expect after some external function is called?
Sure i not rarely see patches fly by where one more memset(,0,) is
used to fully initialize a struct / prevent memory address
disclosures (i only track BSDs).
And there are still patches that fix bugs on old code that
sometimes is twenty years or more, say zlib or tzcode.
And then there are compiler bugs that bring in bugs -- that is not
avoidable, even if the documentation is clear and obvious like
/* The application can compare zlibVersion and ZLIB_VERSION for consistency.
If the first character differs, the library code actually used is not
compatible with the zlib.h header file used by the application. This check
is automatically made by deflateInit and inflateInit.
*/
That is only graspable by a human programmer that reads it. Rapid
application development that surely is not.
(And actually i am not sure this is really true. But i personally
would hope for it. It is more earthy, and has more blood, sweat
and tears.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
12:53 a.m.
Steffen Nurpmeso wrote in
<20230201004023.rHE9j%steffen(a)sdaoden.eu>eu>:
...
P.S.: What i will never forget, it came in the major news TV
program of Germany (ARD Tagesschau, public law; iirc), was when
JAVA came up. Small (Campus?) Cafe in America, two young male
programmers and one young female programmer, and she was asked why
JAVA, .. and she said something like "this is our opportunity".
Maybe this is the thing about the name Rust that i go with.
Whether it makes anything "better", i do not know. But it is
maybe an opportunity for a generation to go/nim/julia their way.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
1:03 a.m.
I think people expect the language to do too much these days, sort of
like if it compiles without warnings then likely as not it works. I
suppose that can be true with some languages if you follow certain
patterns cookbooks, but it's not true of C or any program I ever wrote,
I think this issue is a combination of style and language mechanics. I
recently had to explain to a young manager, why I couldn't look at a
program and tell him definitively whether it works or not. I did
explain, but I don't think he really understood me, and I'm sure he was
disappointed that I wasn't "good enough" to do that. Sort of the
negative proof thing - if I find something wrong, I can make a pretty
convincing argument why it's broken, but if I don't see anything wrong,
that doesn't mean it works, and depending on such reviews without
testing (which is also incomplete, but has the benefit that it may
happen upon something we don't think of) is incredibly dangerous.
I think general software engineering knowledge and experience cannot be
'obsoleted' or made less relevant by better languages. If they help,
great, but you have to do the other part too. As languages advance and
get better at catching (certain kinds of) mistakes, I worry that
engineers are not putting enough time into observation and understanding
of how their programs actually work (or do not).
On 01/31/2023 05:49 PM, Larry McVoy wrote:
Even though I participated in this thread, so I too
have sinned, this
definitely wants to be discussed elsewhere. comp.lang.c maybe?
This discussion reminds a lot of what my career has been like. Over and
over again, I got told "that won't work". I wasn't very interested
in
those people, if they stayed out of my way. I was way more interested
in the people who said "hmm, maybe if you did it this way".
I've written a ton of working C code. I've managed and guided others
to do the same. I'm positive that I've written way more commercially
supported C code than was present in v6/v7 kernels. Not sure about
userspace, I think Unix has me beat there.
The point? It's very possible to write working C code. You need good
programmers and those seem to be going out of style so people are turning
to Rust because it doesn't compile crappy code.
I'm just happy to be retired, C worked for me for 40+ years, I feel
like I dodged a learning curve bullet by getting out before I had to
switch to Rust (or whatever).
On Wed, Feb 01, 2023 at 01:40:23AM +0100, Steffen Nurpmeso wrote:
> ron minnich wrote in
> <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ(a)mail.gmail.com>om>:
> |That example was a simplified bit of code from a widely used code base. All
> |I need to do is change the function g go a pointer to function, or have it
> |be provided by a .so, and all bets are off.
> |
> |In any event, the important thing here is not that y should be initialized,
> |or should not; it's that it is not possible to get a consistent answer on
> |the question, from people who have been writing in C for decades.
>
> I find the syntax just terrible. (I have not programmed with it.)
> I mean annotations are for the better, ok, (but i luckily get away
> with only "const" and "volatile" (and "mutable"), and
leave things
> like "restrict" be a good man). Johannes Lundberg i think it was
> who then left FreeBSD (?) but pointing to a Rust program
> he had written (i cannot find the reference), that was a few years
> ago (i looked once i composed this message first, it might even
> had been as early as 2017!), and i was lucky i do not have to deal
> with it.
>
> Even nim-lang.org that at least converted its code to plain C back
> in the day when it was still called Nimrod is too heavy for me now,
> but claims to be hard realtime aware etc. It at least tries to
> give programmers some syntactic sugar that makes people happy when
> they look at the screen for 7 hours (underpaid) or 16 hours
> (over-ambitioned). Like the only python thing i like, the
> syntax sugar. But as languages grow they get more and more
> "refined", and now i read things like
>
> type
> BinaryTree*[T] = ref object # BinaryTree is a generic type with
> # generic param `T`
> le, ri: BinaryTree[T] # left and right subtrees; may be nil
> data: T # the data stored in a node
>
> proc newNode*[T](data: T): BinaryTree[T] =
> # constructor for a node
> new(result)
> result.data = data
>
> which gets me off a bit and makes me think that "hey, maybe
> Objective-C is not really the worst thing" (despite the syntax).
>
> I do not know. Everything beyond a small monolithic
> self-contained thing is a problem per se. You can then unit test
> atomically, and if thousands of modules do that, you plug them to
> a better whole. But that also not a good answer, all those flakes
> that live their own life, many maybe even in remote locations out
> of any control.
>
> You could have a language which hard fixates all the call chain,
> or you could have tools which bring this to a small and simple
> language which does not offer it. A compiler can figure out which
> variables are assigned etc and could create in-object-file
> annotations which the linker automatically verifies.
> Of course there are many code paths through functions.
>
> Back in 2009 when i bought the one Apple i wanted to have i tried
> out their Development software, which i think required internet
> access. All the pop-ups and titles, i think it (later?) could
> compile on-the-fly and inject the new object in the running tested
> application, etc.
>
> And then there are semantic description languages like interface
> builders, where robots create the actual code. So then you could
> have Corba interface descriptions / DBUS and plug it all via it.
>
> Then Rob Pike says "make it a string" (more or less), and luckily
> i do not have dyslexia.
>
> Maybe Qt has a good answer by not only not banishing the
> C preprocessor, but introducing another one on top.
> So then the compiler can analyze the code and generate a correct
> variable-state-at-function-call-time state that a dynamic linker
> could then verify against the consumer or producer (whatever is
> needed) of linked modules, that link modules, that link modules,
> all of which are subject to replacements due to development
> iterations, bug patches etc, ie, new releases.
>
> As in, the library versioning that is used for ELF object files,
> today often even linker scripts which furtherly diversify this,
> offer are not enough, they do not do this. They only bundle
> a name to a library version, or multiple (as in
>
> 1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3
> 33 FUNC GLOBAL DEFAULT 13 realpath(a)GLIBC_2.2.5)
>
> I do not know how Rust deals with this. Is it at all possible to
> fixate all the call chain over all possibly involved dynamics?
> What do i gain from initializing an object with a default value if
> that default value is not not not not one of the values that
> i expect after some external function is called?
>
> Sure i not rarely see patches fly by where one more memset(,0,) is
> used to fully initialize a struct / prevent memory address
> disclosures (i only track BSDs).
> And there are still patches that fix bugs on old code that
> sometimes is twenty years or more, say zlib or tzcode.
> And then there are compiler bugs that bring in bugs -- that is not
> avoidable, even if the documentation is clear and obvious like
>
> /* The application can compare zlibVersion and ZLIB_VERSION for consistency.
> If the first character differs, the library code actually used is not
> compatible with the zlib.h header file used by the application. This check
> is automatically made by deflateInit and inflateInit.
> */
>
> That is only graspable by a human programmer that reads it. Rapid
> application development that surely is not.
> (And actually i am not sure this is really true. But i personally
> would hope for it. It is more earthy, and has more blood, sweat
> and tears.)
>
> --steffen
> |
> |Der Kragenbaer, The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
1:18 a.m.
New subject: Algol rules: was something about Rust is not C++
On 1/31/23 7:50 PM, Will Senn wrote:
Well, I just read this as Rust is dead...
Rust never sleeps.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
4:34 p.m.
I think you are right, this is an important component, people joining
and identifying themselves with a language movement. And planning to be
there to fill the need for "Language X" programmers.
On 01/31/2023 05:53 PM, Steffen Nurpmeso wrote:
Steffen Nurpmeso wrote in
<20230201004023.rHE9j%steffen(a)sdaoden.eu>eu>:
...
P.S.: What i will never forget, it came in the major news TV
program of Germany (ARD Tagesschau, public law; iirc), was when
JAVA came up. Small (Campus?) Cafe in America, two young male
programmers and one young female programmer, and she was asked why
JAVA, .. and she said something like "this is our opportunity".
Maybe this is the thing about the name Rust that i go with.
Whether it makes anything "better", i do not know. But it is
maybe an opportunity for a generation to go/nim/julia their way.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
443
days inactive
445
days old
17 comments
12 participants
participants (12)
-
Alejandro Colomar -
Andy Kosela -
Blake McBride -
Chet Ramey -
Dan Cross -
Larry McVoy -
Luther Johnson -
ron minnich -
segaloco -
Steffen Nurpmeso -
Stuff Received -
Will Senn