• US White House urges devs to dump C and C++

    From Nightfox@21:1/137 to All on Wed Feb 28 14:28:55 2024
    I saw this article today:
    https://shorturl.at/KMZ07


    Full URL: https://www.infoworld.com/article/3713203/white-house-urges-developers-to-dump- c-and-c.html

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From Digital Man to Nightfox on Wed Feb 28 18:27:02 2024
    Re: US White House urges devs to dump C and C++
    By: Nightfox to All on Wed Feb 28 2024 02:28 pm

    I saw this article today:
    https://shorturl.at/KMZ07

    But BASIC and Assembly are just fine. :-)
    --
    digital man (rob)

    Synchronet/BBS Terminology Definition #19:
    DCD = Data Carrier Detect
    Norco, CA WX: 60.4°F, 74.0% humidity, 5 mph W wind, 0.00 inches rain/24hrs
  • From Ogg@21:3/110.10 to Nightfox on Wed Feb 28 19:06:00 2024
    Hello Nightfox!

    ** On Wednesday 28.02.24 - 14:28, Nightfox wrote to All:

    I saw this article today:
    https://shorturl.at/KMZ07


    Full URL: https://www.infoworld.com/article/3713203/white-house-urges-developers-to- dump- c-and-c.html


    Is the WH a good source for programming advice? :|



    --- OpenXP 5.0.58
    * Origin: fsxnet/2 (21:3/110.10)
  • From Nightfox@21:1/137 to Digital Man on Wed Feb 28 20:30:31 2024
    Re: US White House urges devs to dump C and C++
    By: Digital Man to Nightfox on Wed Feb 28 2024 06:27 pm

    I saw this article today:
    https://shorturl.at/KMZ07

    But BASIC and Assembly are just fine. :-)

    Of course. :)

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From Nightfox@21:1/137 to Ogg on Wed Feb 28 20:31:46 2024
    Re: US White House urges devs to dump C and C++
    By: Ogg to Nightfox on Wed Feb 28 2024 07:06 pm

    I saw this article today:
    https://shorturl.at/KMZ07

    Is the WH a good source for programming advice? :|

    I was thinking that as well.. I wonder if they talked to anyone before suggesting developers drop C and C++.

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From Digital Man to Nightfox on Wed Feb 28 21:50:02 2024
    Re: US White House urges devs to dump C and C++
    By: Nightfox to Ogg on Wed Feb 28 2024 08:31 pm

    Re: US White House urges devs to dump C and C++
    By: Ogg to Nightfox on Wed Feb 28 2024 07:06 pm

    I saw this article today:
    https://shorturl.at/KMZ07

    Is the WH a good source for programming advice? :|

    I was thinking that as well.. I wonder if they talked to anyone before suggesting developers drop C and C++.

    I don't doubt it. Managed languages have been big in security and enterprise app development, anywhere performance or hardware-access isn't the paramount priority, for a long time now. It's not to say that you can't have vulnerabilites in managed software (they happen all the time), they're just a different class of vulnerabilities that are generally easier to find and defend against or fix than the memory issues that plague C and C++ code bases.

    It's honestly not bad advice for most projects (e.g. I don't think Apple accepts apps written in C or C++ in its app store). But keep in mind, Rust supports writing memory-unsafe code too. It's default mode is memory-safe, but it's still subvertable. So Rust might not be the cure-all they think it is.
    --
    digital man (rob)

    Breaking Bad quote #23:
    Whiteboy's gonna kick your ass if you don't stop wasting his time. - Hank Norco, CA WX: 55.0°F, 84.0% humidity, 0 mph NNE wind, 0.00 inches rain/24hrs
  • From Blue White@21:4/134 to Ogg on Thu Feb 29 08:16:21 2024
    https://www.infoworld.com/article/3713203/white-house-urges-developers
    -to-
    dump- c-and-c.html


    Is the WH a good source for programming advice? :|

    I sure wouldn't think so but I have not read the article yet. ;)



    --- Talisman v0.53-dev (Linux/armv7l)
    * Origin: possumso.fsxnet.nz * telnet:2123/ssh:2122/ftelnet:80 (21:4/134)
  • From Blue White@21:4/134 to Digital Man on Thu Feb 29 08:17:06 2024
    I saw this article today:
    https://shorturl.at/KMZ07

    But BASIC and Assembly are just fine. :-)

    And, of course, COBOL!



    --- Talisman v0.53-dev (Linux/armv7l)
    * Origin: possumso.fsxnet.nz * telnet:2123/ssh:2122/ftelnet:80 (21:4/134)
  • From Nightfox@21:1/137 to Digital Man on Thu Feb 29 09:31:20 2024
    Re: US White House urges devs to dump C and C++
    By: Digital Man to Nightfox on Wed Feb 28 2024 09:50 pm

    I don't doubt it. Managed languages have been big in security and enterprise app development, anywhere performance or hardware-access isn't the paramount priority, for a long time now. It's not to say that you can't have vulnerabilites in managed software (they happen all the time), they're just a different class of vulnerabilities that are generally easier to find and defend against or fix than the memory issues that plague C and C++ code bases.

    It's honestly not bad advice for most projects (e.g. I don't think Apple accepts apps written in C or C++ in its app store). But keep in mind, Rust supports writing memory-unsafe code too. It's default mode is memory-safe, but it's still subvertable. So Rust might not be the cure-all they think it is.

    I've sometimes thought it shouldn't be much of an issue if you're always careful about how you write code. There's that adage "the poor craftsman blames his tools".. One thing I like about C and C++ is they don't do much to limit you, but I suppose that can be a blessing and a curse. And human error is always a factor, so I suppose it's good when the programming language can help you avoid introducing bugs and vulnerabilities.

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From tenser@21:1/101 to Digital Man on Fri Mar 1 08:05:50 2024
    On 28 Feb 2024 at 09:50p, Digital Man pondered and said...

    Re: US White House urges devs to dump C and C++
    By: Nightfox to Ogg on Wed Feb 28 2024 08:31 pm

    Re: US White House urges devs to dump C and C++
    By: Ogg to Nightfox on Wed Feb 28 2024 07:06 pm

    I saw this article today:
    https://shorturl.at/KMZ07

    Is the WH a good source for programming advice? :|

    I was thinking that as well.. I wonder if they talked to anyone before suggesting developers drop C and C++.

    I don't doubt it.

    Indeed, they did. There was an extensive public commentary
    period wherein a number of people from industry, academia,
    and government weighed in.

    The WH press release is just that: a press release. The actual
    text is linked, but is rather different. Effectively, the White
    House is just putting out a press release to raise awareness of
    efforts from across the US government.

    Managed languages have been big in security and
    enterprise app development, anywhere performance or hardware-access
    isn't the paramount priority, for a long time now. It's not to say that you can't have vulnerabilites in managed software (they happen all the time), they're just a different class of vulnerabilities that are generally easier to find and defend against or fix than the memory
    issues that plague C and C++ code bases.

    +1e6

    It's honestly not bad advice for most projects (e.g. I don't think Apple accepts apps written in C or C++ in its app store). But keep in mind,
    Rust supports writing memory-unsafe code too. It's default mode is memory-safe, but it's still subvertable. So Rust might not be the
    cure-all they think it is. --

    In the various materials they link to, Rust is just one option
    they mention. Ada SPARK, C#, Java, Python, Rust and Go are all
    listed across the set of publications, as well as non-language
    techniques (like formal methods and verification). Interestingly,
    they mention Rust as being explicitly unproven in space
    applications, while C that's been formally verified is well proven.

    The thing about Rust unsafety is, however, a bit of a red herring.
    Rust _does_ give you the ability to write memory-unsafe code, but
    you have to go out of your way to do so (e.g., via explicit use of
    `unsafe` or other weird shenanigans). But so do most managed
    programming languages (e.g., Java with JNI etc). If one writes
    Rust using the safe subset, you get memory safety and data race
    freedom. Now, async cancel safety, that's another thing entirely....

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From tenser@21:1/101 to Nightfox on Fri Mar 1 08:13:08 2024
    On 29 Feb 2024 at 09:31a, Nightfox pondered and said...

    Re: US White House urges devs to dump C and C++
    By: Digital Man to Nightfox on Wed Feb 28 2024 09:50 pm

    I don't doubt it. Managed languages have been big in security and enterprise app development, anywhere performance or hardware-access i the paramount priority, for a long time now. It's not to say that you can't have vulnerabilites in managed software (they happen all the ti they're just a different class of vulnerabilities that are generally easier to find and defend against or fix than the memory issues that plague C and C++ code bases.

    It's honestly not bad advice for most projects (e.g. I don't think Ap accepts apps written in C or C++ in its app store). But keep in mind, supports writing memory-unsafe code too. It's default mode is memory- but it's still subvertable. So Rust might not be the cure-all they th it is.

    I've sometimes thought it shouldn't be much of an issue if you're always careful about how you write code.

    The thing is, the last 50 years have shown us that this
    doesn't hold. I've seen the best and brightest programmers,
    top researchers and people out of the best academic programs
    in the world, who regularly write C code that is broken in
    some fashion or another.

    There's that adage "the poor craftsman
    blames his tools"..

    True, but only because the good craftsman curates,
    maintains, and carefully chooses his tools for the
    job at hand. A skilled woodworker does not use a
    hammer where a saw is required, and he keeps his saw
    sharp and free of rust because it is safer and he
    knows he'll do a better job. Knowing what tool to
    use, and choosing from the best of tools, is what
    separates the good craftsman from the poor.

    One thing I like about C and C++ is they don't do
    much to limit you, but I suppose that can be a blessing and a curse.
    And human error is always a factor, so I suppose it's good when the programming language can help you avoid introducing bugs and vulnerabilities.

    Indeed. Many of the arguments I'm seeing now seem
    reminiscent of the arguments that were made when
    people stopped writing applications in assembly and
    moved to high (or higher) level programming languages.

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Digital Man to Blue White on Thu Feb 29 13:17:44 2024
    Re: US White House urges devs to dump C and C++
    By: Blue White to Digital Man on Thu Feb 29 2024 08:17 am

    I saw this article today:
    https://shorturl.at/KMZ07

    But BASIC and Assembly are just fine. :-)

    And, of course, COBOL!

    Indeed. https://ibmmainframes.com/about6861.html
    --
    digital man (rob)

    Sling Blade quote #26:
    Karl: kaiser blade, ax handle with long blade on it shaped kinda like a banana. Norco, CA WX: 61.1°F, 66.0% humidity, 3 mph W wind, 0.00 inches rain/24hrs
  • From Digital Man to Nightfox on Thu Feb 29 13:43:46 2024
    Re: US White House urges devs to dump C and C++
    By: Nightfox to Digital Man on Thu Feb 29 2024 09:31 am

    I've sometimes thought it shouldn't be much of an issue if you're always careful about how you write code. There's that adage "the poor craftsman blames his tools".. One thing I like about C and C++ is they don't do much to limit you, but I suppose that can be a blessing and a curse. And human error is always a factor, so I suppose it's good when the programming language can help you avoid introducing bugs and vulnerabilities.

    It's an issue. The fact that we're still finding memory-safety bugs in both new/modern and age-old (well vetted) C and C++ code is a testament that it is indeed an issue.

    There is no single programming language that is the best tool for everything. For systems programming (OS kernels, device drivers, firmware), C and C++ are still tools of primary choice (though Rust is making some inroads here). But if I were to develop just about anything else that lives, privacy/security, or business operations depended upon, I'd use a managed language/environment.
    --
    digital man (rob)

    This Is Spinal Tap quote #36:
    Bobbi Flekman: Money talks, and bullshit walks.
    Norco, CA WX: 61.0°F, 68.0% humidity, 4 mph NW wind, 0.00 inches rain/24hrs
  • From k9zw@21:1/224 to Nightfox on Thu Feb 29 11:55:15 2024
    Here is the actual report:

    http://tinyurl.com/mr35enkr

    https://www.whitehouse.gov/wp-content/uploads/2024/02/ Final-ONCD-Technical-Report.pdf

    When you take out the obvious political BS, which is slathered through out, the idea of migrating towards lower risk models by updated langauge
    selection makes sense.

    That the admin heads (Biden or Harris) even know what this is all about ... well that is rather suspect and is the political wrappings around the
    good people's work.

    --- Steve K9ZW via SPOT BBS

    --- Mystic BBS v1.12 A48 2022/07/15 (Linux/64)
    * Origin: SPOT BBS / k9zw (21:1/224)
  • From Nightfox@21:1/137 to Digital Man on Thu Feb 29 19:27:31 2024
    Re: US White House urges devs to dump C and C++
    By: Digital Man to Nightfox on Thu Feb 29 2024 01:43 pm

    There is no single programming language that is the best tool for everything. For systems programming (OS kernels, device drivers, firmware), C and C++ are still tools of primary choice (though Rust is making some inroads here). But if I were to develop just about anything else that lives, privacy/security, or business operations depended upon, I'd use a managed language/environment.

    I suppose it would make sense to use a managed language/environment.
    In some of the newer C++ standards, they've introduced some classes that are meant to help manage memory better for you though, suchas shared_ptr, unique_ptr, etc.. I've heard people say you can avoid using new & delete (or malloc() and free()) and use those managed pointers instead. I think another issue can be buffer overruns though, and I don't recall offhand if a managed language normally protects against that. In a quick Google search, I found a page where someone said buffer overflow exploits are possible in C#, though it's harder to produce them in C#.

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From Nightfox@21:1/137 to k9zw on Thu Feb 29 19:27:53 2024
    Re: Re: US White House urges devs to dump C and C++
    By: k9zw to Nightfox on Thu Feb 29 2024 11:55 am

    When you take out the obvious political BS, which is slathered through out, the idea of migrating towards lower risk models by updated langauge selection makes sense.

    Yeah, I agree it makes sense.

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From tenser@21:1/101 to Nightfox on Sat Mar 2 02:30:06 2024
    On 29 Feb 2024 at 07:27p, Nightfox pondered and said...

    Re: US White House urges devs to dump C and C++
    By: Digital Man to Nightfox on Thu Feb 29 2024 01:43 pm

    There is no single programming language that is the best tool for everything. For systems programming (OS kernels, device drivers, firmware), C and C++ are still tools of primary choice (though Rust i making some inroads here). But if I were to develop just about anythi else that lives, privacy/security, or business operations depended up I'd use a managed language/environment.

    I suppose it would make sense to use a managed language/environment.
    In some of the newer C++ standards, they've introduced some classes that are meant to help manage memory better for you though, suchas shared_ptr, unique_ptr, etc.. I've heard people say you can avoid using new &
    delete (or malloc() and free()) and use those managed pointers instead.
    I think another issue can be buffer overruns though, and I don't recall offhand if a managed language normally protects against that. In a
    quick Google search, I found a page where someone said buffer overflow exploits are possible in C#, though it's harder to produce them in C#.

    The problem with the new facilities in C++ is that they
    don't address the underlying problem, and they don't
    automatically retrofit themselves onto the many billions
    of lines of existing code. The sharp edges are still
    there in the language, and a programmer has to proactively
    go out of the way to avoid them.

    The situation with most managed/memory-safe languages is
    sort of the opposite. They're safe by default, but usually
    have some escape hatch where you can do things that are
    unsafe. But you have to go out of your way to do those
    things.

    Bjarne Stroustrup gave a talk recently about making C++
    more safe and the gist of it that I took away was that he
    wants to address much of the safety concerns by teaching
    programmers to write C++ differently (e.g., teach them to
    use the newer idioms, `unique_ptr`, etc). That could
    certainly help, but again, history has shown us that this
    doesn't scale particularly well, and in languages like C
    and C++ where "undefined behavior" is both endemic and
    gives compiler writers lots of leeway to mangle code in
    unexpected ways (and UB in C can time travel up until C23!),
    code that appears to work for _years_ can suddenly stop
    doing so when you update a point revision of your compiler.
    It's madness.

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Ben Collver@21:2/101 to Nightfox on Fri Mar 1 10:12:34 2024
    Re: US White House urges devs to dump C and C++
    By: Nightfox to All on Wed Feb 28 2024 14:28:55

    Congratulations, the White House has caught up to the 1980s ;)

    gopher://gopherpedia.com/0/Ada_%28programming_language%29
    --- SBBSecho 3.20-Linux
    * Origin: End Of The Line BBS - endofthelinebbs.com (21:2/101)
  • From Digital Man to tenser on Fri Mar 1 10:56:13 2024
    Re: Re: US White House urges devs to dump C and C++
    By: tenser to Nightfox on Sat Mar 02 2024 02:30 am

    code that appears to work for _years_ can suddenly stop
    doing so when you update a point revision of your compiler.
    It's madness.

    It's also the reason so many commercial and open source "linters" (static analyzers) and run-time analysis tools exist today (primarily, for use with C and C++ projects) - detecting undefined behavior, security issues. The unsafety of C and C++ have kept a lot of people busy for a lot of years. :-)

    I've definitely seen what you're describing though - hey this worked before I upgraded the tools, it must be a bug in the tools! <sigh> It's almost never a bug in the tools. :-(
    --
    digital man (rob)

    Rush quote #62:
    He's a restless young romantic, wants to run the big machine .. New World Man Norco, CA WX: 57.6°F, 66.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs
  • From Nightfox@21:1/137 to Digital Man on Fri Mar 1 11:44:58 2024
    Re: Re: US White House urges devs to dump C and C++
    By: Digital Man to tenser on Fri Mar 01 2024 10:56 am

    code that appears to work for _years_ can suddenly stop doing so when you
    update a point revision of your compiler. It's madness.

    It's also the reason so many commercial and open source "linters" (static analyzers) and run-time analysis tools exist today (primarily, for use with C and C++ projects) - detecting undefined behavior, security issues. The unsafety of C and C++ have kept a lot of people busy for a lot of years. :-)

    I've definitely seen what you're describing though - hey this worked before I upgraded the tools, it must be a bug in the tools! <sigh> It's almost never a bug in the tools. :-(

    Years ago I was working on a C++ project where sometimes we'd update to a newer version of the compiler, and a bug in a section of the code would start showing up. It was obvious to me it was a bug in the code, and I wondered how it seemed to work fine when we were using the previous version of the compiler.

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From tenser@21:1/101 to Digital Man on Tue Mar 5 05:47:41 2024
    On 01 Mar 2024 at 10:56a, Digital Man pondered and said...

    Re: Re: US White House urges devs to dump C and C++
    By: tenser to Nightfox on Sat Mar 02 2024 02:30 am

    code that appears to work for _years_ can suddenly stop
    doing so when you update a point revision of your compiler.
    It's madness.

    It's also the reason so many commercial and open source "linters" (static analyzers) and run-time analysis tools exist today (primarily, for use with C and C++ projects) - detecting undefined behavior, security
    issues. The unsafety of C and C++ have kept a lot of people busy for a
    lot of years. :-)

    Oh yeah. A lot of the argument for C/C++ is that one
    can use static analysis tools to catch errors that the
    compiler won't; that's all well and good, but yeah, it
    keeps us busy.

    Also, some bugs are just hard to catch. At one point,
    we got told at Google to stop using unsigned integers
    to index into arrays and instead use signed integers,
    because unsigned overflow is well-defined in C, but
    signed integer overflow is UB, so could be detected with
    UBsan. /shrug

    I've definitely seen what you're describing though - hey this worked before I upgraded the tools, it must be a bug in the tools! <sigh> It's almost never a bug in the tools. :-(

    Yup. :/

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)