[HN Gopher] Nvidia Security Team: "What if we just stopped using...
___________________________________________________________________
Nvidia Security Team: "What if we just stopped using C?"
Author : q-big
Score : 222 points
Date : 2022-11-07 10:49 UTC (12 hours ago)
(HTM) web link (blog.adacore.com)
(TXT) w3m dump (blog.adacore.com)
| user8501 wrote:
| If we risk societal collapse because of buffer overflows, I think
| our society needs fixing, not our fun and sharp creative tools.
|
| Personally I think "what if we stopped using npm?" and "what if
| we stopped using cargo?" are much better security questions to be
| asking at this point.
| tyree731 wrote:
| There may be better questions, but we aren't only allowed to
| ask the best possible question.
| khiqxj wrote:
| > 1999
|
| > CPUs are now 1GHz
|
| > C is obsoleted outside small sections of code such as image
| processing
|
| > 23 years later
|
| > "What if we just stopped using C?"
| marcosdumay wrote:
| This is about image processing.
| cameroncooper wrote:
| I actually enjoy programming in C. I don't get to use it as much
| as I'd like to though. Almost all the work I do these days has
| some other language that makes more practical sense to use:
| JavaScript, Golang, Rust, etc. But coming from an ECE background
| I enjoy the low level nature of C.
| kshacker wrote:
| The problem is not the people who are proficient and enjoy the
| language. The problem is the people of the other kind who get
| told to do it for a living. I know the top level asbestos
| analogy (not mine) got shot down but let me try another. The
| problem is that we send both a trucker and cyclist to the
| freeway without any kind of protections for or against cyclist.
| brundolf wrote:
| Possibly naive question from someone who's never worked with this
| kind of language, but something I've been wondering about:
|
| > it is possible to prove mathematically that your code behaves
| in precise accordance with its specification
|
| So that bridges from one thing to another; but what prevents
| flaws in the specification itself? Is it just simpler/easier to
| read than the code is, so they're easier to spot?
| csb6 wrote:
| > Is it just simpler/easier to read than the code is, so
| they're easier to spot?
|
| Kind of. You basically annotate your program with pre/post-
| conditions, then you run the program through a theorem prover,
| which attempts to prove all of your conditions are true in all
| cases.
|
| The basic guarantee is that if you pass the theorem prover,
| your code will be free of array out-of-bounds accesses, null
| pointer dereferences, integer overflow, divide by zero, and
| other runtime errors. These are useful security properties to
| prove always hold, and you don't have to explicitly write
| specifications for them (just conditions to help the prover
| along).
|
| If you want to go further (prove functional correctness of your
| program), you can add more specifications. A lot of times you
| just want to prove some basic sanity checks hold 100% of the
| time (e.g. always return a sorted array). These can be pretty
| easy to specify correctly.
| the_only_law wrote:
| Ada is one of those languages that I really like in theory, but
| don't really get to use it because I'm usually better off picking
| something else (for any number of reasons, but right tool for the
| job, y'know)
| mark_l_watson wrote:
| Ada had many good ideas, but I can't imagine using it for
| anything but existing large legacy code bases.
|
| I am impressed by the Swift language: nice REPL based
| development if you want that, typed, great support for Apple
| devices and some support for Linux.
| yjftsjthsd-h wrote:
| Er, does Swift have _any_ of Ada 's safety properties or
| proof tooling?
| wiseowise wrote:
| > Swift
|
| > REPL based
|
| What?
| mark_l_watson wrote:
| I don't use Swift very often, but when I do, I use the REPL
| to experiment with new code snippets, just as I would for
| Lisp languages, Julia, or Python.
| 3a2d29 wrote:
| Isn't reference counting a type of garbage collection?
|
| I feel like you can't put Swift in the world of
| Rust/Ada/C/C++
| q-big wrote:
| > Isn't reference counting a type of garbage collection?
|
| Reference counting leads to memory leaks if cycles occur.
| Garbage collection algorithms don't have this problem.
| 3a2d29 wrote:
| I checked and you are not correct.
|
| https://en.m.wikipedia.org/wiki/Garbage_collection_(compu
| ter...
|
| Reference counting is a type of garbage collection.
| q-big wrote:
| On the other hand:
|
| "Garbage collection vs. ARC"
|
| https://atp.fm/205-chris-lattner-interview-transcript#gc
| (Hacker News:
| https://news.ycombinator.com/item?id=31139610)
|
| This (sub)headline only makes sense if garbage collection
| and ARC are different concepts.
| 3a2d29 wrote:
| Hmm I think they are referring to GC as "traditional" GC,
| but I will concede that they don't seem to say that.
| mark_l_watson wrote:
| True enough. I probably should not have inserted Swift into
| an Ada conversation. BTW, I am a Lisp developer, but some
| reason I find Swift palatable.
| tgsovlerkhgsel wrote:
| In the end, how many people "speak" a language matters a lot
| more than its properties, both in the real world (compare
| Esperanto and other designed languages vs. English) and with
| programming languages.
|
| If language A is "better" but language B has all the libraries
| and developers, the right choice is usually still B.
| wiseowise wrote:
| Not if language A pays twice language B.
| davidork wrote:
| pjmlp wrote:
| If you bothered to read the link you would have found out that
| it is about firmware written in Ada/SPARK, that is even lower
| level than raw drivers.
| krylon wrote:
| I didn't even read the link, but it points to Adacore, which
| is a not-very-subtle hint what language it's going to be
| about.
| P_I_Staker wrote:
| GO is stupid and I don't respect it
| mogoh wrote:
| https://web.archive.org/web/20221107104951/https://blog.adac...
| anuvrat1 wrote:
| OT: Please post an archived link in comments, especially for
| small blogs
|
| Edit:
| https://web.archive.org/web/20221107114522/https://blog.adac...
| unequiv88 wrote:
| xet7 wrote:
| That PDF was slow to load, but here it is:
|
| https://web.archive.org/web/20221107153324/https://releases....
|
| https://releases.wekan.team/ada/222559-adacore-nvidia-case-s...
| jollyllama wrote:
| Security teams 10 years ago: Hey, why are you using that library?
|
| Security teams today: Hey, why are you using that language?
| cookiengineer wrote:
| Once the same kind of programming mistakes reappear in every
| other library, all over again, you start to question the
| language paradigms.
|
| Humans are not good at programming. I've never seen a "done"
| C++ codebase in my life, maintainers are always too busy
| reinventing parts that had originally nothing to do with the
| feature scope of their library.
| treeman79 wrote:
| I can't even imagine getting back into C and knowing where to
| begin to do it "right" and get to a useful level.
| jfhufl wrote:
| I think that's the major problem with software engineering in
| general: when is software "done" ?
| nmz wrote:
| When you can no longer remove anything else.
| jlarocco wrote:
| > Humans are not good at programming. I've never seen a
| "done" C++ codebase in my life, maintainers are always too
| busy reinventing parts that had originally nothing to do with
| the feature scope of their library.
|
| No reason to limit to "C++" there. It's an industry wide
| problem with every language. Even in open source, if a repo
| hasn't had commits in the last week, most people treat it as
| a dead project.
| TheLoafOfBread wrote:
| Security teams in 10 years: Hey, why are you programming?
| pjmlp wrote:
| C.A.R Hoare in 1980,
|
| "Many years later we asked our customers whether they wished us
| to provide an option to switch off these checks in the
| interests of efficiency on production runs. Unanimously, they
| urged us not to--they already knew how frequently subscript
| errors occur on production runs where failure to detect them
| could be disastrous. I note with fear and horror that even in
| 1980, language designers and users have not learned this
| lesson. In any respectable branch of engineering, failure to
| observe such elementary precautions would have long been
| against the law."
| Joel_Mckay wrote:
| What if all problems were solvable by adding or removing a layer
| of abstraction?
|
| Perhaps, like any other tool-set... C has an optimal problem
| domain not everyone can understand, and it is often unrelated to
| llvm compilers.
|
| Those who failed to learn why C++ evolved into its current state,
| are simply doomed to naively make another iteration of the same
| tantalizing bad design choices.
|
| https://en.wikipedia.org/wiki/Second-system_effect
| deltasevennine wrote:
| >Perhaps, like any other tool-set... C has an optimal problem
| domain not everyone can understand
|
| Maybe this is true specifically for C. However you imply this
| is true for "any other tool-set".
|
| This is also a form of bias. It is illogical and irrational to
| think that every tool set is good for something. Things that
| exist can be horribly bad for everything and things that exist
| can in theory be good for almost anything.
|
| There is not magical rule that says all tool-sets are great
| because they're always optimal for some niche problem domain.
|
| The universe is not made up of apples and oranges. There are
| rotten oranges and rotten apples as well.
| Joel_Mckay wrote:
| Languages like Python/C# have fundamentally broken threading
| models. And yet people like to use these for cluster work.
| Kind of like eating steak with a spoon, as you never knew
| about forks.
|
| There are often language specific features that are not
| isomorphic, and are the primary reason a language was
| developed in the first place. =)
| pclmulqdq wrote:
| Abstraction is probably the most expensive (and bug-ridden)
| thing we do in computing. For OS writers and users, it is not a
| good idea to add any more abstraction than you absolutely need.
| billfruit wrote:
| There is benefits to using better and better tools as they are
| being invented and evolved. In many aspects C is a primitive
| tool.
| Joel_Mckay wrote:
| NodeJS project: 441MB, 32872 dependencies, and uptime <5 days
| due to patching cycles
|
| C project Version: 2.5MB, 6 dependencies, and uptime 3+ years
| (OpenSSL patch ended the streak.)
|
| Being busy is not necessarily productive, and "Better" is
| often use-case dependent. =)
| kevingadd wrote:
| Who's proposing replacing C with NodeJS? In the context of
| a discussion of how using verifiable/safe by design
| languages is an alternative to C?
| Joel_Mckay wrote:
| It was in jest of a "Novelty bias" assertion. ;)
| wiseowise wrote:
| How long did it take to build both?
|
| How fast can you add features to both?
|
| How easy it is to find developers for both?
| Joel_Mckay wrote:
| I will let you know if the NodeJS underwear stain on my
| budget ever finishes.
|
| ;)
| ilyt wrote:
| So how you wrote same app that have half a gig of
| dependencies in NodeJS ?
|
| I have 10+ year Perl app that never needed fixing but I
| don't present it as an example of Perl being better than
| everything.
|
| Also JS is a particularly bad language in near-every
| respect and not even in same category as C so I dunno why
| you compare them in the first place.
| Joel_Mckay wrote:
| Perl was awesome when no other options were available.
| And one will find many languages inherited its features,
| as is was great for parsing text.
|
| "So how you wrote same app that have half a gig of
| dependencies in NodeJS ?"
|
| Nope, some have greatness cast upon them... great heaping
| piles of steaming greatness... One likely already knows
| the greatness of which I speak. ;)
| maratc wrote:
| The fundamental theorem of software engineering (FTSE) is a
| term originated by Andrew Koenig to describe a remark by Butler
| Lampson attributed to David J. Wheeler: "We can
| solve any problem by introducing an extra level of
| indirection." The theorem is often expanded by the
| humorous clause "...except for the problem of too many levels
| of indirection," referring to the fact that too many
| abstractions may create intrinsic complexity issues of their
| own.
|
| https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
| Joel_Mckay wrote:
| Yes, written by someone who has never inherited a code-base
| hundreds of juniors patched over 12 years. At that point, you
| launch a separate division, slowly transfer functional
| support, and jettison the old structure after a year.
|
| ;)
| agentultra wrote:
| It's a funny aphorism at best but I don't think software
| would work nearly as well if there were more than a grain of
| truth to it.
|
| Think of all the layers of abstraction that have led to this
| moment, you reading this comment, me writing it: the
| hardware, the operating systems, libraries, run-times, the
| network... it's immense. And it's a wonder that it works so
| well let alone at all.
|
| I like this quote but I think it applies to _weak_
| abstractions; ie: not abstractions at all but, as they say,
| indirection and obfuscation. Using the word "abstraction"
| has done a lot of harm to efforts to convey the importance
| and utility of various formal methods from property testing
| to proof automation. A solid abstraction has fundamental laws
| and properties. It aids in mastering complexity rather than
| hinders.
| warinukraine wrote:
| > "We can solve any problem by introducing an extra level of
| indirection."
|
| It's worth keeping in mind that this isn't a fundamental law
| of the Universe. Not all abstraction layers are equally good.
| Just because it's possible to do a bad job at something
| doesn't mean we can't try and do a good job.
| Dylan16807 wrote:
| C on a modern compiler is very abstract, and the abstractions
| are an insecure pain in the ass.
| whalesalad wrote:
| With things like WASM and GraalVM this is becoming more and
| more realistic. We don't really write ASM anymore because it's
| tedious and error prone, same can be said for C. I wouldn't
| choose it today unless I absolutely had to. Abstraction is the
| way.
| Joel_Mckay wrote:
| The annoying part is having to endure the Astroturfing
| campaigns.
|
| I'd prefer a clear 1 liner in Julia or Prolog over 80 pages
| of unknown correctness. ;)
| qsort wrote:
| And the language you use to target WASM is... C?
|
| I'm not necessarily saying it's a _good_ language, but it 's
| an excellent abstract machine. It won't die.
| SkyMarshal wrote:
| Just about every language can compile or transpile to WASM:
|
| https://github.com/appcypher/awesome-wasm-langs
| pjmlp wrote:
| There are plenty of WASM runtimes without any C on them.
| qsort wrote:
| I'm not talking about the language you use to write the
| runtime. I'm talking about the language you use to write
| the code that becomes the WASM that the runtime runs.
| They not need be the same.
|
| As others have pointed out you can compile pretty much
| everything to WASM, but it's most often done with the
| same languages you'd use to compile to native code; C,
| C++, Rust, the usual suspects.
| pjmlp wrote:
| D, Go and C# use their own bootstrapped compilers, just
| to give three examples from many others.
| pjmlp wrote:
| Already in 1961, one of the achievements of Burroughs was
| being an OS fully written in a safe systems languages (one of
| the first uses of UNSAFE code blocks), and a bytecode based
| format for executables.
|
| This system is still sold nowadays as Unisys ClearPath MCP.
| meltyness wrote:
| This is a wrong interpretation of the obvious solution,
| enforcing sane standards for the typical imperative patterns
| used and assuming feasibility of static analysis.
|
| Programmer as user just makes sense once you've moved past
| punch cards to interactive IDEs. Everyone should have stopped
| using punch cards by now, but lo-and-behold this is still
| basically the standard in some outfits.
| Joel_Mckay wrote:
| In some remote places... weaving machines still use punch
| cards, as the factory has run for over a century without
| electricity.
|
| One can never assume our use-case assumptions will
| generalize. =)
| meltyness wrote:
| Right, but they almost certainly have on-hand a skilled
| reviewer that verifies that good-faith programmers haven't
| done anything incorrectly that would bork a machine.
|
| ... that step wouldn't constitute introducing an
| abstraction either.
| marcosdumay wrote:
| How will undefined operations change with your new layer of
| abstraction?
|
| Anyway, you are really claiming that a sandbox capable of
| running C programs will solve more problems than writing your
| code in Rust?
| Joel_Mckay wrote:
| I am inferring languages like Rust are not a replacement, but
| rather focus on a different problem domain already addressed
| in higher level languages.
|
| Its not a complete waste of time, but I have yet to see a
| use-case only Rust features could better achieve. I am not
| smart, so may have missed something important. =)
| marcosdumay wrote:
| > languages like Rust
|
| Hum... If you know other languages similar to Rust, I'm
| curious to know them. Maybe there is something better out
| there, but AFAIK, the closest thing in existence is C.
|
| > a different problem domain already addressed in higher
| level languages
|
| Things like device drivers and embedded software. It's also
| what people push into submission when they want high
| performance software, but this is always a hard thing to
| do.
|
| I do really not recommend you to use Rust if a higher level
| language solves your problem.
|
| > I have yet to see a use-case only Rust features could
| better achieve
|
| It helps achieving things like making sure your GPU driver
| fucking works, instead of doing what the nvidia driver
| does.
|
| Of course, this article is about a different way of making
| sure it works. One that requires a lot more of work, but
| can provide some assurances that Rust can't. It is also
| easier to apply over Rust than C, but neither are the best
| target for it.
| Joel_Mckay wrote:
| "making sure your GPU driver fucking works"
|
| Well I did notice how nVidia left out the part that the
| CUDA C API had a known bug that would crash on exit due
| to a de-allocation bug for years. Thus, C++ became the de
| facto interface for their GPU library.
|
| All code is terrible, but some of it is useful (except
| rust and VB). ;)
| docandrew wrote:
| C is like asbestos. It was fine at what it did, good performance,
| but the safety problems outweigh them. The difference is that we
| _stopped using asbestos_ because it was unsafe. It's still around
| but being replaced during renovations, and no new installations
| use it.
|
| For whatever reason with C there's this huge emotional component
| to it. Safer alternatives exist. You'd rightfully laugh at a
| contractor who suggested asbestos is fine, if you make sure to
| use only highly-skilled installers who patch up the drywall so
| that no fibers can escape. But with C we say that all the time,
| and the CVEs keep piling up.
| sokoloff wrote:
| There are still industrial uses of asbestos today, because for
| some applications, there isn't a ready drop-in replacement.
| Uses where safer drop-in replacements were possible (shingles,
| automotive friction materials, flooring, insulation) have gone
| away. That might be a good comparison against "portable
| assembly", also known as C.
| vanattab wrote:
| Out of curiosity what are the modern uses for asbestos?
| Agrue8u wrote:
| https://www.propublica.org/article/asbestos-poisoning-
| chemic...
| blagie wrote:
| I think the problem NVidia has is that it has a massive low-
| level high-performance computing infrastructure written in C.
| Things like WebGL are a thin veneer over it, which is
| terrifying.
|
| Their use combines the proper use of C (low-level driver
| code) with the unsafe use (large-scale systems). They should
| absolutely stop using C. On the other hand, I think it's fine
| for my network driver.
| paulmd wrote:
| I was talking with someone in charge of coordinating WebGL
| rollout with various IHV driver teams and they said while
| AMD and NVIDIA were definitely annoyed at the work it was
| going to take, Intel was the one where the team reacted
| with sheer terror.
|
| Maybe that speaks to some of the driver problems they're
| having now, if their house just wasn't in order beforehand.
| blagie wrote:
| The cynic in me says that Intel is the only vendor of the
| three who has thought about security before.
|
| I am willing to bet that NVidia and AMD's GPU unit have
| floodgates of vulnerabilities along the lines of Spectre,
| which they simply never had to deal with before (not to
| mentions likely hundreds of more basic ones).
| epistasis wrote:
| I think a better analogy may be nuclear power, than asbestos,
| because of the labor side of the tech.
|
| Using nuclear power correctly takes a ton of engineering
| prowess, lots of additional construction. If done well, it
| works great. When it goes bad, it goes really bad.
|
| So if it's 1982, maybe nuclear power or C is a good option. If
| it's 2022, new technology may provide a cheaper way of getting
| to the same end point, with less engineering and construction,
| and probably even less cost.
| [deleted]
| adgjlsfhk1 wrote:
| This is a worse analogy because good nuclear plants exist.
| With C, I've yet to see a widely used library written by
| multiple humans in C that doesn't have critical memory bugs.
| fxtentacle wrote:
| Linux comes pretty close for practical usage. Or sqlite.
| adgjlsfhk1 wrote:
| https://www.cvedetails.com/product/47/Linux-Linux-
| Kernel.htm... and
| https://www.cvedetails.com/vulnerability-
| list.php?vendor_id=.... Linux has new security
| vulnerabilities found every year due to memory issues
| caused by C.
| wiseowise wrote:
| Nuclear power yields amazing results compared to
| alternatives, this isn't the case with C.
| Workaccount2 wrote:
| Forgive my ignorance, I'm a hobby embedded programmer at best,
| but aren't many programming languages built right on top of C?
| Is the whole lineage unsafe, or is it really just C?
| pannSun wrote:
| When people say "C is unsafe", what they mean is "it is too
| easy to create unintended vulnerabilities when writing C".
| The language won't catch your mistakes, and some of those
| mistakes are dangerous. "Safety" in this context means
| "language, compiler, or runtime features to prevent, catch,
| or mitigate mistakes made by human programmers".
|
| So this doesn't actually affect things built _on top of_ C.
| E.g. transpiling Rust to C won 't make it any less safe
| because C is "unsafe" - Rust has its own safety features,
| that work regardless of compile target.
|
| Or think of it this way - assembly language is even more
| unsafe than C, yet everything (including C) is built on top
| of that.
| paulmd wrote:
| Transpiling rust to C is still dangerous if you don't
| control the compiler on the other side - _one of the many_
| footguns with C is thinking that there is any "inherently
| safe" C code. There isn't, because tomorrow the optimizing
| compiler may optimize away your null checks or start
| optimizing away your variables due to aliasing, and this
| danger is ever-present because of the sweeping nature of
| "undefined behavior" in C.
|
| C is safe if you are using a 1970s-style compilers that
| don't perform optimizations, or perform a limited and
| predictable subset. C that is passed through an optimizing
| compiler (which in the context of this comment is all
| modern compilers) can never be inherently safe unless you
| conform strictly to the "undefined behavior" spec which is
| impossible in practice.
|
| In contrast transpiling (really this is just compiling)
| Rust to assembly should never be unsafe, because you know
| there is no additional transformation step. Or at least,
| unless the processor has an implementation flaw... which
| is, of course, the whole thing about Spectre/Meltdown.
|
| C has far far too many things in the "unsafe behavior"
| categories that really should just be compiler errors. But
| like "implementation-dependent" behavior in general, this
| was seen as an advantage at the time, it makes it possible
| for low-power or esoteric hardware to be driven with C
| code. But in modern high-level software development
| contexts, this makes it a foot-howitzer to try and use.
| pannSun wrote:
| Thank you for the correction. I agree with everything you
| wrote, and should have known better and added a caveat
| regarding the difficulty of correctly divining the
| behavior of a C program, instead of assuming compiler
| writers are flawless omniscient beings.
| Dylan16807 wrote:
| Why don't you think it's possible to avoid undefined
| behavior in machine-emitted C?
|
| Machine-emitted C can avoid most of the language,
| guarantee it won't incorrectly alias anything, and
| guarantee bounds are always checked.
|
| Bugs are possible but you can make Rust->C bugs no more
| likely than Rust->assembly bugs.
| M4v3R wrote:
| Not really. Many programming languages compile themselves
| nowadays (it's called bootstrapping) so there's no direct C
| lineage in them.
| NekkoDroid wrote:
| gnarbarian wrote:
| yes. if the compiler was written in c and there is a bug in
| the compiler that language could be tainted.
| AlotOfReading wrote:
| Anything where a human is writing C is probably unsafe.
| Machine generated C can also be unsafe, but I'm unaware of an
| epidemic of systematic issues resulting from it the way we
| get with human C.
| c-baby wrote:
| myth_drannon wrote:
| Ouch, that's a hurtful analogy. I was about to start playing
| with Turbo C on my 486, ordered K&R book...
| smcl wrote:
| I think it is a little bit melodramatic as an analogy. It's
| perfectly fine to tinker with C, to use it in personal
| projects, to use it where it's not possible to use something
| safer (some embedded system that Rust doesn't have a backend
| for) or if you want to contribute to an existing project like
| Linux, OpenBSD or CPython. Whereas it's _really_ not a good
| idea to work with Asbestos under _any_ circumstances.
|
| But the message overall - that maybe we don't need to
| instinctively reach for C for newbuild low-level programming
| anymore - is probably about right
| docandrew wrote:
| As long as it doesn't have a modem you're probably safe.
| Probably.
| Dylan16807 wrote:
| Were you planning to write production software on your 486? I
| don't see why it should hurt you at all.
|
| If there's a joke here I missed it, sorry.
| lelanthran wrote:
| > Ouch, that's a hurtful analogy.
|
| It's also wrong. A lot of the time the people making these
| types of comments about C are just plain bitter that their
| favourite $NEW_LANGUAGE is mostly a rounding error in terms
| of usage.
| wiseowise wrote:
| > A lot of the time the people making these types of
| comments about McDonald's are just plain bitter that their
| favourite $3_STAR_MICHELIN_RESTAURANT is mostly a rounding
| error in terms of visitors.
| lelanthran wrote:
| > A lot of the time the people making these types of
| comments about McDonald's are just plain bitter that
| their favourite $3_STAR_MICHELIN_RESTAURANT is mostly a
| rounding error in terms of visitors.
|
| That's true too; what's your point?
| Dylan16807 wrote:
| The supposed bitterness doesn't actually make their
| criticism of McDonald's wrong.
| mmis1000 wrote:
| I guess you need to know it enough to know why people don't
| want them now.
|
| Like, everyone knows typescript catches more human mistake
| that JavaScript. But you won't know why if you don't know
| JavaScript at first place.
| noobermin wrote:
| So it's not everything but as long as operating systems are
| written in C, it will be the language of choice for many
| projects.
| kazinator wrote:
| We use all sorts of hazardous materials, which are safe if
| properly used, transported and stored.
|
| C is not "unsafe" in the sense that little bits of it break off
| in installations and make people sick, but in the sense that
| the assurance of safety almost all rests on the programmer.
|
| If code is safe, and not changed, it stays that way.
| ploxiln wrote:
| C in software stacks is more like flame in kitchens. Fire is
| dangerous and bad for your health. Kitchen fires kill people,
| gas leaks kill people. It's possible to do without. But
| billions of people around the world cook with flame and do OK.
| All our ancestors did, and here we are. There will always be
| professional kitchens that use gas/flame (almost all of them).
| And it'll always be possible for your food to catch on fire
| anyway, if you cook it wrong.
|
| Unlike asbestos insulation in houses, or flame in your personal
| kitchen, you actually can't avoid C in your software stack. Do
| you use Linux, FreeBSD, or OpenBSD, or macOS, or Windows? Do
| you use Postgres or MySql or sqlite, or maybe redis or
| memcached? How about a language like Python or JS or Java or
| Ruby or Lua? Do you use rust? guess what the business-end of
| that compiler is written in! so you dabble at the tippy-top of
| the stack in some language like rust or go, so what?
| ClumsyPilot wrote:
| > Unlike asbestos insulation in houses, you actually can't
| avoid C in your software stack
|
| You know what, construction industry could have made the same
| argument - oh look, all insulation suppliers use asbestos,
| the factory is built out of it too, its everywhere in the
| supply chain, you can't actually avoid asbestos if you ate
| trying to build a house, so we should learn to live with it.
|
| You can't avoid fossil fuels, you gave to use fossil fuels to
| produce a solar panel, so dreaming about clean energy is
| pointless.
|
| The difference is that some i industries pull the finger out
| of their bum and clean up their act, and some i dustries,
| like our's, does not. Even thoigh perfectly serviceable
| alternatives exist.
| bitL wrote:
| I despise this security-first attitude. It just leads to so
| much mental fatigue everywhere and any step is a potential
| minefield. It's ruining programming.
| ironmagma wrote:
| > any step is a potential minefield
|
| That's the exact problem with C. It's the tool, not the
| attitude, which is a problem.
| flohofwoe wrote:
| Securely containing untrusted user code so that it can't do
| any harm is ultimately the responsibility of the OS, or
| whatever sandbox the code is running in.
|
| Language-level memory safety is useful for eliminating an
| important class of bugs, but if those bugs can be exploited
| to escape the sandbox, then that's the problem of the
| sandbox, not of the buggy program running in that sandbox.
| So please, by all means, write the sandbox itself in a
| memory safe language like Rust, but requiring the same for
| all code running inside the sandbox is nothing more than an
| admission of failure.
| ilyt wrote:
| That's pretty limited way to look at it. You don't need
| to escape the sandbox to do harm.
|
| You can have your app in perfect sandbox where nothing
| can escape then have a memory safety bug inside allowing
| user to get to the stuff of another user (because your
| sandboxed app talking with sandboxed database still have
| one set of credentials to do everything)
|
| There is of course https://xkcd.com/1200/ for that.
|
| And no "move that separation to DB" _also_ isn 't a
| solution.
| flohofwoe wrote:
| I agree, same with popular multiplayer games for instance
| which could be exploited by memory safety bugs in the
| network protocol implementation. But these are cases
| where just implementing a couple of critical modules
| either with a memory-safe language, or using code
| generation (or both) to reduce the amount of 'manual
| bugs' go a long way. AFAIK exploits almost always happen
| in places where data comes into the system, so those are
| the places to focus on.
| timbit42 wrote:
| What if the sandbox, kernel, device drivers are written
| in C? Sounds like a good case against C for these uses.
| flohofwoe wrote:
| Yes, I fully agree! But such subtleties are usually
| overlooked by the 'C users are criminals' crowd ;)
| optymizer wrote:
| > It was fine at what it did
|
| No need to talk in past tense. C is still the best language at
| what it is meant for: writing fast software. Not safe software,
| _fast and portable_ software.
|
| > but the safety problems outweigh them
|
| Safety is to speed what security is to convenience. Frankly,
| most of the arguments I see today are just fear mongering. In
| my experience, there is no protecting users from developer
| mistakes that lead to software exploitation and 'unsafety',
| independent of the language being used. Memory issues are a
| common avenue, but if you take it away, the next issue will
| become the main avenue for exploitation, and you'll be back in
| the same spot, with the next generation of developers fearing
| that the new software safety level is insufficient to reach
| some ideal safety level, all while having traded off real world
| speed across the board to reach that point.
|
| > no new installations use it
|
| I'm writing a tool in C. It doesn't need to be perfectly
| secure. It does need to be fast.
|
| By using C we acknowledge that users want speed, more than they
| want safety, and that's our developer reality. That doesn't
| mean users don't want safety, it just means that outside of
| specialized domains, on average speed takes priority - people
| have been voting for decades that they want speed more than
| safety, and the process of deciding the priority is as you'd
| expect: users use money to buy a faster product and companies
| selling software invest in making their software fast first.
|
| The security argument is also weak. The whole point of cracking
| software is to find flaws in existing systems, regardless of
| the language they were coded in. One thing will always be true:
| anything that sends data can be cracked. You can only make the
| entry bar harder, but you will not create a language that is
| significantly safer and as fast as C because the optimizations
| that make software fast (like not checking array lengths, not
| checking for overflow, etc) are also the ones making it less
| secure.
|
| One can create a language that's safer than C and fast (in
| specific situations), but there will always be people cracking
| the core of whatever the 'safe' language du jour is, so you
| will have decreased security incidents on average, but have not
| eliminated them, while leaving room for a competitor to swoop
| in with a faster product that's safe enough, and it's your
| users who will decide who wins, not you.
|
| Just to emphasize this, so far, I have not seen any indication
| that the general population will shift to picking safety over
| speed, so you'd be betting against your users.
| lelanthran wrote:
| > For whatever reason with C there's this huge emotional
| component to it.
|
| Frankly getting your knickers in a knot is emotional - the
| people using C are doing so for pragmatic reasons, not emotion.
|
| I do see comments like yours a lot - there's an emotional
| attachment and/or ego attached to the comment, so the argument
| against is very vociferous and, honestly, ugly[1].
|
| [1] C and asbestos have almost nothing in common in terms of
| negative impact on the world. Maybe people are still using C
| because hyperbole is simply not a persuasive argument.
| bpye wrote:
| > Frankly getting your knickers in a knot is emotional - the
| people using C are doing so for pragmatic reasons, not
| emotion.
|
| I think a lot of us using C would like to move away, but for
| whatever reason can't. One example is that we hotpatch our
| binaries, but that sort of infrastructure doesn't exist for
| Rust.
|
| Beyond tooling issues, that certainly can be fixed, it's also
| non trivial to move a large codebase to a safer language.
| Maybe incremental use of languages like Rust is still better?
| meltyness wrote:
| You don't seem to address the "pragmatic reasons" expressly,
| so I'll go ahead and do it:
|
| 1. "Don't rewrite code" a fundamental precept of software
| that has been "engineered" - This is more
| about development lifecycles than something that contributes
| usefully to software quality in the long term. Corporations,
| and people haven't been treating these things like bridges or
| overpasses
|
| 2. Outsourcing is believed cheaper than the solution.
| - Again, paying low-wage junior SEs to patch uncovered bugs
| is obviously cheaper than proactively finding them all.
|
| 3. You can sell the New Coke too! - If you
| have a good rewrite, sell it at a fat markup, and keep
| selling the old crap too, it's not your risk. -
| Obviously don't rewrite unless your horrid monolithic source
| leaks, and you're certain that it's a problem, those
| disgruntled workers you wrongfully laid off know too much.
|
| 4. If your tech references are a security risk, sell those
| too! - Don't include pesky manuals where
| people can uncover issues with your development processes,
| outsource a minimum blackbox of guess work to Singapore and
| let that double as QA. - It's not a manual, it's
| 'training' -- supporting education of hopeful workers! Wow!
|
| I won't name any names.
| zamalek wrote:
| > I do see comments like yours a lot - there's an emotional
| attachment and/or ego attached to the comment
|
| Could you explain how it's emotional? It comes across as a
| pretty logical analogy to me - the author isn't suggesting
| that they don't like C (which would be categorically
| emotional), they are comparing it to phasing out something
| unsafe in another industry.
| ectospheno wrote:
| A truth stated passionately doesn't become false. A
| falsehood stated calmly doesn't become true. This is at the
| heart of why emotion is always a logical fallacy.
|
| Everyone would be better served by using and hearing it
| less. Focus on the actual argument.
| zamalek wrote:
| I am neurodivergent, so I may be missing something here.
| The argument seems pretty passionless. Excluding the
| assumption that C is unsafe, it contains purely facts.
|
| Your reply doesn't point out the passionate component of
| it either, and doesn't answer my question.
| ulfbert_inc wrote:
| Analogy is not an argument.
| wiseowise wrote:
| Unsafe C is a fact, there's no need for an argument in
| their comment.
| naasking wrote:
| > Analogy is not an argument.
|
| Just for sake of clarity, formal analogy is a valid, non-
| fallacious argument because it's based on parity of
| reasoning.
|
| The original comment made a pretty good, arguably formal
| analogy between asbestos and C. The only way to dismiss
| the conclusion is if there were no alternative to
| asbestos, then you're kinda forced to use asbestos. This
| is the case for C in some contexts, like some
| microcontrollers that only come with C compilers. It's
| not generally true that we need C for much else though.
| IncRnd wrote:
| > Analogy is not an argument.
|
| "An analogical argument is an explicit representation of
| a form of analogical reasoning that cites accepted
| similarities between two systems to support the
| conclusion that some further similarity exists." [1]
|
| [1] https://plato.stanford.edu/entries/reasoning-analogy/
| zamalek wrote:
| That _still_ doesn 't point out the emotion in the
| comment. Your reply here would work as a reply to the
| root comment, but doesn't address what I am asking at
| all. Where is the passion?
| Jtsummers wrote:
| Asbestos is an emotionally charged topic for many people,
| especially the many who have (primarily) older relatives
| who have died or are dying from cancers caused by it. The
| analogy is resting primarily on the appeal to that kind
| of emotion without actually establishing a strong logical
| similarity between C and asbestos.
| zamalek wrote:
| That makes sense, thank you.
| macintux wrote:
| > Asbestos is an emotionally charged topic for many
| people, especially the many who have (primarily) older
| relatives who have died or are dying from cancers caused
| by it.
|
| I've not personally been impacted by this, but this seems
| reasonable.
|
| > The analogy is resting primarily on the appeal to that
| kind of emotion
|
| This seems like projection. It struck me as a perfectly
| legitimate analogy without any emotional correlation.
| Jtsummers wrote:
| I don't know, C isn't out there causing cancer and
| killing people left and right. It's hyperbolic to draw
| that comparison. Critical systems (especially post
| Therac-25) that are using C are already using a subset of
| C, static analysis tools, and comprehensive testing that
| raise the quality level of actual life-and-health-
| impacting C programs.
|
| EDIT: Because someone will probably make a note of it:
| Therac-25 wasn't written in C, but the flaws in that
| system and others helped lead to a massive change in the
| way critical systems are developed and treated. I
| referenced it because it's one of the most notable
| failures in safety-critical software systems.
| macintux wrote:
| It's fine to argue that the analogy is flawed (all of
| them are) or that it's irrelevant, or simply wrong.
|
| What this entire thread is about, however, is this highly
| charged response to what seemed like a straightforward
| analogy.
|
| > Frankly getting your knickers in a knot is emotional -
| the people using C are doing so for pragmatic reasons,
| not emotion. > I do see comments like yours a lot -
| there's an emotional attachment and/or ego attached to
| the comment, so the argument against is very vociferous
| and, honestly, ugly[1].
| zamalek wrote:
| At the end of the day it seems as though an emotional
| argument occurred in the eye of the beholder. This only
| adds even more credibility to the root comment.
|
| A failed experiment with the Socratic method on my part.
| Gibbon1 wrote:
| Also point out that there is nothing that can be done to
| fix asbestos. But C can be made safer. The three things
| that block that are
|
| 1 A culture that thinks API's need to always have a
| gotcha. See the inability to to field a safe string copy.
|
| 2 ISO commitee that thinks it's in charge of maintaining
| a historical artifact. Suggestions to change the language
| like Brights suggestions about passing arrays fail
| because the ISO committee thinks that's Heresy.
|
| 3 People that think C is hopeless. Usually these are
| people that had a bad time with it in school.
|
| 4 Idiots that think the only reason to use C is speed.
| Therefor any improved way of doing things that might be
| 10-20% slower than raw unsafe code is pointless.
| ulfbert_inc wrote:
| Fine, but that leaves us with passionless non-argument.
| How is it helpful?
| nvrspyx wrote:
| Sure it is, depending on the analogy and the purpose of
| the analogy. An analogy also isn't always fallacious. It
| needs to have a faulty extrapolated assumption from the
| comparison.
|
| In this particular case, the argument is that C should be
| replaced with something safer for similar reasons that
| asbestos is replaced with something safer. However, one
| can certainly challenge the validity of this comparison
| and whether there's something faulty in it.
|
| I don't feel one way or the other because I don't work
| with C or other low-level languages, but it's a bit
| absurd to say that an analogy isn't an argument. It
| absolutely can be if the argument within is clear, even
| if fallacious.
| ulfbert_inc wrote:
| Thanks for clarifying. I meant valid, non-fallacious
| argument.
|
| More often than not I see analogies (ab)used as a tool to
| construct a straw man. This particular case demonstrates
| how analogy takes discussion away from merits and
| downsides of C to an emotionally charged subject of
| cancerogenic substances, as other commenters highlighted
| in this thread.
| nvrspyx wrote:
| Personally, I don't think it's the commenter's fault that
| some others have such strong emotions to the analogy that
| they're distracted from the point. There's no indication
| that the commenter was appealing to emotion and, as
| others have also pointed out, making a comparison to an
| "emotionally charged" subject does not nullify the
| validity of the comparison. In fact, it's fallacious to
| falsely invalidate the argument based on some cherry-
| picked, subjective, peripheral perspective like that. In
| my opinion, the appeal to emotion and the derailment of
| the discussion is from those doing so, not the original
| commenter.
|
| It seemed like just a simple, general, easily-mappable
| analogy that most people would get, even non-programmer
| laymen, that emphasizes that unsafe should be replaced
| with safe. Any analogy of something unsafe can be seen as
| "emotionally charged" if someone was personally impacted
| by it.
| lelanthran wrote:
| > I am neurodivergent, so I may be missing something
| here.
|
| Yes, you're missing the logic.
|
| > Excluding the assumption that C is unsafe, it contains
| purely facts.
|
| You think C is carcinogenic and mere exposure to it
| kills?
|
| From a "purely facts" PoV, leaving all emotion aside, C
| runs, and has done so for a number of decades, life-
| critical systems, including munitions, weapons, life-
| support, industrial machinery and aviation.
|
| It's only because you are married to your argument that
| you think comparing C to a fatal poison is "pure facts".
| tryauuum wrote:
| I hate all analogies with physical world, because the
| person tends to pick up the most emotional one. It's
| emotional because they picked the thing that makes my lungs
| bleed. C, with all its flaws, doesn't damage my physical
| health.
|
| You call it a logical analogy, how an analogy can be
| logical?
|
| EDIT: and I hate analogies because, since they suck,
| someone will try to come up with a better analogy. And now
| we have a thread where people compare C to asbestos, then
| they compare C to a fire in kitchen. Not a kind of thread I
| would like to be in.
| rcarr wrote:
| How can you hate all analogies with the physical would?
| How do you propose somebody learns something completely
| abstract without any physical counterpart whatsoever? How
| do intend to teach people something as simple as numbers
| without using your fingers or some other quantity of
| items in the world?
|
| Vast quantities of language is built on analogy. _Stream_
| ing, the inter _net_ , the World Wide _Web_ , Star
| _ship_. The word "cycle" comes from the Latin for
| "circle". The list goes on.
|
| I struggle to even comprehend how someone can hold this
| opinion. Have you ever tried instructing anyone in
| anything?
| P5fRxh5kUvp2th wrote:
| zamalek wrote:
| Sure, maybe the analogy isn't logical.
|
| > It's also logical to kill young children with autism so
| they don't become a financial or emotional burden on
| their family or society as a whole. It turns out claiming
| something is logical isn't, itself, enough of a reason to
| do something and those doing so should endeavor to give
| more convincing arguments.
|
| That's an analogy, and we are talking about a programming
| language - not humans.
|
| Again, where is the passion in the original comment? I
| have asked for nothing more than that.
| P5fRxh5kUvp2th wrote:
| > That's an analogy, and we are talking about a
| programming language - not humans.
|
| Is it your supposition that asbestos was banned for non-
| human reasons?
|
| Or does this "logic" only work when convenient for your
| own defenses?
| tomp wrote:
| _> Safer alternatives exist._
|
| Do they? The only "safe" comparable alternative is _unsafe_
| Rust which as the name suggests isn't actually safe.
| jesse__ wrote:
| You're right. Alternatives that tick all the boxes that C
| does, and are also safer, do not exist.
|
| This guy is just doing the typical religious yelling about
| people doing their jobs (writing kernels, drivers, browsers,
| games, etc) with the most flexible tool for programming we've
| developed to date.
|
| Maybe one day Rust will become dominant. Maybe someone will
| overhaul the aliasing rules of C, write some similar lifetime
| tracking tooling, and it will live on for another 50 years.
| Who knows. The reason people still use C and C++ isn't
| because they're good languages (or even that people like
| them, as the comment states), it's that until recently there
| have been very few viable alternatives, and for some domains
| literally none at all. They've largely been the only option
| for a long time.
| notriddle wrote:
| The article is about Ada SPARK, and nVidia using it to
| develop their firmware _today_.
| jesse__ wrote:
| Yes, I wasn't referring to the article, I was referring
| to the person comparing C to asbestos.
|
| It makes sense for nVidia to trade development time and
| prefer a language with formal verification for their
| firmware.
| nordsieck wrote:
| > The only "safe" comparable alternative is _unsafe_ Rust
| which as the name suggests isn't actually safe.
|
| And for some applications, Rust isn't even an alternative.
| Not every chip is supported by LLVM.
| georgeecollins wrote:
| That's a great analogy. I like C, and when people resist it I
| worry about their programming skills. That may not be fair, but
| sometimes the complexity of C / C++ is a version of complexity
| you will see in a big application.Sometimes the complexity is
| needless, confusing, dangerous-- insert what you hate here.
|
| But really Rust seems to have the qualities I like about C and
| less problems. Also, all the reasons I used to have for wanting
| to be "close to the metal" are getting abstracted away in
| hardware. I think the only remaining reasons to use C is the
| huge existing code base.
| 3a2d29 wrote:
| Although the article is about Ada, which is technically more
| memory safe than rust.
| tmtvl wrote:
| I'd like to see the Ada guys, and especially the SPARK
| guys, talk about Rust the way Rust people talk about C.
| That said, I'm just gonna add ACL2 to my Common Lisp
| toolbox and then I too will have the power of theorem
| proving.
| flohofwoe wrote:
| A couple of points from somebody who enthusiastically writes
| new C code every day:
|
| > ...the complexity of C / C++
|
| In this case, please don't throw C and C++ into the same
| bucket, C++ is vastly more complex than C.
|
| > Rust seems to have the qualities I like about C
|
| ...a subset of Rust has those qualities, but the whole of
| Rust has the same problems as C++: overboarding complexity
| both in the language and stdlib.
|
| To lure C users over to a memory-safe language, we need a
| programming language that just adds the comptime memory-
| safety features to a 'small language' like C, but none of the
| higher level features (which only serve to split the language
| community into different tribes - which is also the biggest
| problem of C++).
|
| Finally: yes, C is not memory safe, but when 'language-level
| memory safety' is essential for security, then there's
| something fundamentally wrong with the sandbox the compiled C
| code runs in.
| AmpsterMan wrote:
| I actually find that Go has the qualities of C that I like.
| Namely, simpler language constructs and no classes.
| adgjlsfhk1 wrote:
| Even if a C program is sandboxed, lots of programs handle
| sensitive data that memory errors can leak. For a simple
| example, even in a sandbox, a memory error could pretty
| easily lead to being able to grab another user's password
| out of memory.
| danenania wrote:
| "...when 'language-level memory safety' is essential for
| security, then there's something fundamentally wrong with
| the sandbox the compiled C code runs in."
|
| Doesn't the problem then just become what do you write the
| sandbox in? If you have security-critical code that can't
| be sandboxed, because it _is_ the sandbox, then it seems
| that language-level safety is your only remaining defense?
| flohofwoe wrote:
| Yes, it definitely makes a lot of sense to write the
| sandbox in a memory safe language like Rust. Not even the
| most die hard C fan would argue against that ;)
| jstimpfle wrote:
| Depression can be bad, too. Maybe it can lead to cancer, and it
| undisputedly causes deaths.
|
| Other languages make me depressive and steal my focus. They
| make me go to great lengths trying to get the simplest things
| done. In C, it's like memset(p, 0, sizeof *p), done. Other
| languages make it such that I always code on 3 layers of
| abstraction to not have to do the "hard" task, but now I don't
| know the implementation of those layers. They make it such that
| I'm constantly torn to come up with an even more clever thing
| to say the same things, with even more abstractions and moving
| parts. They pull so much attention to themselves, distracting
| from the task that I want get done. With C, this is not the
| case.
|
| Maybe with a different personality, I could be similarly or
| even more productive in Rust, ignoring all the kitsch in its
| ecosystem. But I've started reading Rust projects dozens of
| times and have always turned away. They always use one more
| abstraction than I can be arsed to look up, always hide the
| most interesting and motivating parts behind a crate
| dependency.
|
| This is not the case with C, where it is easy to find good
| (enough) code that is honest and direct, and rewarding. I know
| that C is not perfect. We're having an open relationship, and I
| don't have any attachments (besides knowing it well) that
| prevent me from jumping ship when I find a better one.
| nspattak wrote:
| In my opinion, the problem is that we failed to create some
| additional layers on top of C. an extended std lib with data
| structs and algorithms as well as a style/practices for
| everyday use (ie non compiler writers).
|
| i adore C, it was my first language and i still like its
| simplicity very much. Still, I have come to believe that only
| strictly vetted licensed people should be allowed to use it :)
| ilyt wrote:
| That doesn't stop bugs, that just makes them less likely. VS
| making them impossible on accident
| pclmulqdq wrote:
| There are an incredibly large number of analysis tools for C
| to check things like memory safety. It doesn't look like they
| are always used in important code, though.
|
| A lot of memory safety CVEs come down to "we wrote a static
| analyzer and found a latent memory bug here."
| timbit42 wrote:
| Maybe a language with the checking by default in the
| compiler would be a good idea, like Ada or SPARK.
| spenczar5 wrote:
| This is not a very useful analogy. It suggests that we should
| regulate C out of existence. But regulation was appropriate and
| effective for a particular reason with asbestos.
|
| We stopped using asbestos because of the link between its
| manufacture/installation and lung cancer. It's a clear case
| where government regulation helps deal with a market failure:
| asbestos is cheap and effective, so consumers like it, but
| nobody involved in asbestos transactions bears the cost of the
| lung cancers the industry causes.
|
| Writing C doesn't make underpaid programmer die early deaths.
| The issues with C are borne directly by the customers who are
| using C software. It's not really a market failure of any kind.
| docandrew wrote:
| I don't think the federal government should step in and
| regulate it, but why not some kind of professional or trade
| organization, like UL?
|
| And really, I think your argument bolsters my case. Federal
| and state governments are freaking out about cybersecurity
| and protecting infrastructure and voting systems, so why
| shouldn't they ban the use of software written in C in their
| acquisition process?
| flohofwoe wrote:
| Such regulations already exists, see for instance
| https://en.wikipedia.org/wiki/MISRA_C. Similar rules could
| be created for Rust (I would assume that this would have to
| be some sort of 'sane subset' of Rust, which for instance
| would forbid dynamic memory allocation alltogether).
| topdancing wrote:
| Or you could use https://en.m.wikipedia.org/wiki/SPARK_(p
| rogramming_language) which is already a formal defined
| language and literally the thing discussed in the link
| right at the top.
| 411111111111111 wrote:
| > _The issues with C are borne directly by the customers who
| are using C software. It's not really a market failure of any
| kind._
|
| While I agree that equating a programming language to a
| carcinogenic substance is inherently wrong, your argument is
| partially false too.
|
| The cost is born by the costumers of the software, not the
| developers. In that sense, it's actually directly opposed to
| your point.
| spenczar5 wrote:
| Isn't that what I said? I don't see any difference.
| 411111111111111 wrote:
| If you did then I dont understand the point you're making
| with the given example.
|
| with the language you've got * the
| creators of C * the developers writing software
| (tool/library/whatever) with C * the users which
| use this software
|
| If the software has a security issue, the cost will have
| to be born by the users, not the developers.
|
| That makes it (imo) directly opposed to your argument, as
| its technically the same as with the carcinogenic
| substance * the creators of the substance
| dont get cancer * the contractors using it to build
| the house dont get cancer * the people that live in
| the house get cancer
|
| (but the people that use software written in C dont ...
| die, which is why I agree that its wrong to equate them)
| _hexley_ wrote:
| I see where your confusion stems from. In the case of
| asbestos, it is the contractors using it to build the
| house who tend to experience adverse health effects, and
| not always the people who live there. Asbestos is
| harmless when it's inert in the wall, paint, etc. The
| danger is when you start doing construction / renovations
| and the dust is free floating.
|
| So OP's point is correct. The two situations are not
| exactly analogous.
| RoyTyrell wrote:
| Well the creators of the substance (manufacturers who
| used asbestos in their products) and the contractors that
| installed the products did in fact also get cancer.
|
| You're both a little bit wrong, and both want to be
| right, so seem to be ignoring the negative aspects of
| both your arguments.
|
| C does not have a direct proven link to causing death or
| catastrophic disease like asbestos does, but any bugs due
| to language "allowing" the dev to shoot themselves in the
| foot is largely born by the users - at least initially.
| littlestymaar wrote:
| Asbestos is killing mostly the contractors instead of the
| users, which is breaks the analogy here. (That being
| said, any argument using the "market failure" concept is
| dubious from the beginning)
| [deleted]
| [deleted]
| encryptluks2 wrote:
| Rust is like Scientology. At one point it was considered
| scientific. Then at some point it was no longer accepted
| because it became a cult.
| [deleted]
| potta_coffee wrote:
| I've never given Rust a chance because I'm utterly repulsed
| by the community.
| jimlongton wrote:
| > Safer alternatives exist.
|
| Sure, but do they have certified compilers for Functional
| Safety (ISO26262) development for Automotive or Medical
| applications? Rust does not, although there's a company working
| on it.
| docandrew wrote:
| Yes, the compiler used for the work described in the post:
| https://www.adacore.com/industries/automotive/iso26262
| hackerbrother wrote:
| More asbestos! More asbestos!
| paulmd wrote:
| https://www.dailymail.co.uk/news/article-3091148/Chilling-
| im...
| qualudeheart wrote:
| MISRA C avoids those security flaws in a big way.
| TazeTSchnitzel wrote:
| I wish that were true. It imposes a lot of restrictions but
| doesn't solve the fundamental issues of C.
| googlryas wrote:
| To adjust your analogy a little, we actually still use
| asbestos, but it just isn't used for the general public. It
| still has unique properties that are industrially or
| commercially useful, such as certain asphaltic roofing
| compounds and friction products like brake pads.
|
| But, it isn't used in products designed for the general public
| where strict oversight can't generally be provided.
| ethbr0 wrote:
| This is the key point that's often missed: asbestos isn't
| used anymoee _in applications where the risks outweigh the
| benefits_.
|
| We use incredibly dangerous materials in photolithography,
| nuclear weapons production, armor piercing projectiles, and
| aerospace... because there are no alternatives and/or the
| benefits outweigh the risks.
|
| What changed is that we learned more about asbestos (it
| causes cancer) and phased it out of applications where
| alternatives existed, even more expensive ones.
|
| In the C analogy, there may be places C continues to make
| sense... but it shouldn't be used anymore out of default,
| because it's the way things have always been done, or any
| other reason that doesn't end with "... and that's more
| important than an increased risk of security
| vulnerabilities."
| nordsieck wrote:
| > For whatever reason with C there's this huge emotional
| component to it. Safer alternatives exist.
|
| For a lot of things, I just don't think this is true.
|
| For example, here is sqlite's reasoning for choosing C:
| https://www.sqlite.org/whyc.html
|
| I can't say I can really disagree with it.
| wizofaus wrote:
| That article wins the argument for me, and I'm not a fan of C
| particularly. Admittedly it doesn't address security
| concerns, but the fact they're able to achieve 100% machine
| code level branch coverage (I wonder if that includes the
| possibility of executing injected code...) should go a long
| way towards generating confidence that there are no readily
| exploitable vulnerabilities.
| spamizbad wrote:
| There are many C developers out there who will insist they have
| gained enough experience to never write code vulnerable to
| various memory safety exploits. Real "I actually drive safer
| slightly buzzed" vibes.
| wiseowise wrote:
| > Real "I actually drive safer slightly buzzed" vibes.
|
| "I don't need seatbelts, I actually know how to drive unlike
| others"
| mumblemumble wrote:
| It's not an emotional component, it's just plain old network
| effects.
|
| Unfortunately, a lot more switching cost is involved in getting
| embedded and systems programmers and platforms over to a new
| programming language, than is involved in getting construction
| contractors and industrial engineers to choose a different
| material.
| mmis1000 wrote:
| Lots of them just have their own toolchain and language
| subset. Make porting literally impossible. Because you don't
| know how the original one works.
|
| And c like language on these embedded devices are probably
| due to the fact that it's the easiest way to implement a
| programming language(abstraction) that work on bare metal.
| marcosdumay wrote:
| People also had a large and unexplainable emotional attachment
| to asbestos.
| delusional wrote:
| Believing that all software security problems would be solved
| if we got rid of C is a bigger disease than C itself. I work in
| a fairly large (for my country) financial institution and the
| problems we deal with on a day to day basis are so far removed
| from buffer overflows that it's not even funny.
|
| We still have software running in excel macros that control web
| browsers via COM. C is nothing compared to the attack surface
| of that.
| zamalek wrote:
| > Believing that all software security problems would be
| solved if we got rid of C is a bigger disease than C itself.
|
| Getting rid of a class of errors (correctness) allows you to
| focus more on other errors (logical). It could be argued that
| it could slightly reduce the likelihood of the latter.
| P5fRxh5kUvp2th wrote:
| Our industry went through this with the move to Java (and
| later .Net).
|
| "It will solve memory leaks!"
|
| ...
|
| "whoops, you can still leak memory in garbage collected
| languages, my bad everyone!".
| hardware2win wrote:
| I dont remember single mem leak in my half decade .net
| career
|
| which speaks how rare they are
| P5fRxh5kUvp2th wrote:
| .net 1.0 was 20 years ago, you've been working in it for
| 5 years, roughly 25% of its lifetime.
| hardware2win wrote:
| We're evaluating techs by their state decade(s) ago here
| or what?
| P5fRxh5kUvp2th wrote:
| judgment is not the only reason for conversation, I
| strongly suggest you read back over the conversation from
| the beginning and endeavor to understand the context with
| which responses are made.
|
| I also suggest you say 5 years instead of "half-a-
| decade", most of us see through that and it's off-
| putting.
| zamalek wrote:
| I have worked with .Net, in a hobby capacity, since beta.
| I have worked with it professionally since 2007.
|
| I have seen two instances of rooted memory:
|
| - WPF. The implicit GC root path introduced by events. We
| were easily able to track this down due to the
| information that the GC holds in memory[1] (fixing it was
| not so easy).
|
| - A leak in managed C++ (non-pure, i.e. native code). We
| had to use the normal tools to track this down, not a 5
| minute diagnosis.
|
| At the end of the day GC'd languages can have (and
| usually do) richer tooling surrounding memory usage. They
| are better in this regard even during a failure state.
|
| [1]: https://learn.microsoft.com/en-
| us/dotnet/core/diagnostics/so...
| adgjlsfhk1 wrote:
| ditching C doesn't solve memory leaks but it does solve
| use after free. A memory leak is a performance problem
| that isn't generally exploitable. A use after free is
| almost always a security vulnerability.
| P5fRxh5kUvp2th wrote:
| quick, someone tell everyone locking up resources without
| releasing them isn't exploitable for bad actors.
| wiseowise wrote:
| In C you leak memory because of all the land mines in the
| language. In Java/.Net you leak memory because you have
| flaw in your logic.
| paulmd wrote:
| Circular references and other things that tend to leak
| memory on GC languages aren't a logic flaw in the sense
| of your business logic being wrong or your algorithms
| being bad, though. They're things the language allows you
| to do, that can be completely correct at a business level
| and visually correct at a code level, but result in
| fundamental breakage of the VM's operation.
|
| I say this as someone who does high-level languages as a
| day job, and doesn't find them to be a problem
| personally, but, yeah, Java as a concept still allows
| some unintuitive footguns like that.
|
| Difference in magnitude of impact, difference in the
| response of the standards organizations in handling it,
| but yeah it's certainly _same kind_ of footgun as C lets
| you do. The difference being that Java has devoted an
| enormous amount of resources to squashing these errors
| and they largely aren 't a problem anymore, where C is
| afraid to touch the "undefined behavior" and
| "implementation dependent" sacred cows.
|
| Is there an unspoken social contract between language
| committee and language users that aliasing a variable or
| causing a circular reference should not shoot your dog
| and burn down the house? That's the fundamental
| disagreement between Java and C's standards bodies.
| scawf wrote:
| Circular reference does not leak memory if your using a
| proper GC
| donkeybeer wrote:
| Memory errors are always logic errors in C. Freeing
| something that was already freed or accessing a buffer
| out of bounds and so on are pure logic errors.
| zamalek wrote:
| From my comment, emphasis added:
|
| > it could _slightly_ reduce
| bcrosby95 wrote:
| Both a paper cut and a gunshot wound bleed. It doesn't
| make them equal.
| [deleted]
| mejutoco wrote:
| OP is not claiming that it would reduce _all_ software
| security problems though, so this is a straw man (intentional
| or not).
|
| Even the analogy holds up in this regard: using other
| materials instead of asbestos does not remove all the
| construction problems.
|
| I think C has other things going for it (simplicity of the
| compiler), just wanted to point that out.
| GeekyBear wrote:
| > Believing that all software security problems would be
| solved if we got rid of C is a bigger disease than C itself.
|
| According to studies done at Google and Microsoft, about 70%
| of their serious security issues are a result of memory
| safety errors.
|
| >Around 70 percent of all the vulnerabilities in Microsoft
| products addressed through a security update each year are
| memory safety issues; a Microsoft engineer revealed last week
| at a security conference.
|
| https://www.zdnet.com/article/microsoft-70-percent-of-all-
| se...
|
| and
|
| >Nearly 70% of the high severity security bugs in Chrome's
| code are memory unsafety problems, Google's engineers have
| revealed.
|
| https://tech.hindustantimes.com/tech/news/70-of-security-
| bug...
| docandrew wrote:
| Ok, but why are the Excel macros so risky? It's often because
| the underlying software or OS was written in C/C++.
| Jtsummers wrote:
| Excel macros are risky because they offer a kind of
| privilege escalation. Most Excel built-in functions (that
| is, what you write into the cells) have limited reach. They
| impact that cell and (by reference) other cells, but not
| the underlying filesystem and other things. Even looking at
| the database ones, I'm not seeing a single function that
| writes to the DB but plenty that read from it, that's
| "safe" in that it would be very hard to abuse these kinds
| of things to screw with other systems or the host system.
| But macros can run arbitrary code and access whatever the
| user can access in a way most Excel functions cannot and
| can trigger arbitrary effects. The equivalent of `rm -r ~/`
| is not possible in straight Excel, but is feasible with a
| macro. C and C++ have nothing to do with that, it's the
| underlying privilege model that permits it.
|
| There's a good case to be made for using better languages
| than C and C++ for large classes of software. Don't weaken
| it by making absurd claims.
| P5fRxh5kUvp2th wrote:
| > There's a good case to be made for using better
| languages than C and C++ for large classes of software.
| Don't weaken it by making absurd claims.
|
| And this idea can be applied to so many things.
|
| Seriously, very often things have enough downsides that
| you don't need to exaggerate things that are not
| downsides. You're actually weakening your side by doing
| so because if people cannot trust even that bit of
| honesty, why would they trust anything you say?
|
| be trustworthy is the first rule in convincing others.
| docandrew wrote:
| Broken security model/sandboxing aside (which is
| inexcusable), the use of C/C++ expands the attack surface
| - there are some excel exploits though that take
| advantage of C vulns like buffer overflows:
| https://www.exploit-db.com/exploits/18087
| snicker7 wrote:
| You can be socially engineered to open a mallacious excel.
| delusional wrote:
| What? No it isn't. It's because the users think they're
| opening a document to look at some data and suddenly it's
| an executable transferring money via their bank account.
|
| And that's all working as designed. Someone built it like
| that. There's no bug anywhere in that chain, just as
| extremely rickety system with no affordances for human
| intervention. No separation of what is trusted and what is
| not.
| wizofaus wrote:
| Did you see the claim "70% of all security bugs are related
| to memory safety"? Which isn't to say 70% of successful
| exploitation of said bugs resulted in genuine harm, but low-
| level vulnerabilities in widely used system-level software
| (network stacks etc.) can potentially have devastating
| effects in the way an excel macro is unlikely to.
| delusional wrote:
| What I'm trying to get at here is that security is not just
| "bugs". Nowhere in the excel macro hell that is my job are
| there any bugs. Using a macro to transfer money in and out
| of peoples accounts in bulk is bad design, It's insecure,
| and i have at times argued that it's unethical, but it is
| also not a bug, It's exactly how the system was designed to
| work. Edge was designed to embed an Internet Explorer OLE
| frame, and that frame was designed to have an IE7
| compatibility mode. No part of that would count in the "70%
| of bugs" list.
|
| Moreover, almost no bugs are discovered in the actual
| reasonable software we have. That's not because we are the
| best engineers, or because we write it with the utmost care
| and attention to detail. It's because we're a total of 5
| people (mostly a couple of years out of uni) looking at it.
| C, and other systems programming languages are greatly
| overrepresented in the corpus of software that is actually
| being combed through for bugs. Java and Cobol are heavily
| underrepresented.
|
| I want to make this clear again. I work in banking. If 2008
| showed us anything it's that banking underpins most of our
| modern society so these quality issues are not unimportant,
| they can be devastating.
| 3a2d29 wrote:
| I was expecting this to be a rust article lol.
|
| Ada is more memory safe than rust technically, although with less
| devs using it.
| pornel wrote:
| Except dynamic memory allocation, which in Ada either needs a
| GC or is unsafe.
| 3a2d29 wrote:
| And rust is unsafe if you use unsafe rust (or even if you use
| Arc in safe rust and reference count incorrectly).
|
| Ada doesn't use allocation, remaining 100% memory safe.
| twic wrote:
| > And rust is unsafe if you use unsafe rust (or even if you
| use Arc in safe rust and reference count incorrectly).
|
| I don't believe it's possible to cause unsafety using Arc
| in safe Rust. I don't know what "reference count
| incorrectly" means here. Could you explain?
| vitiral wrote:
| I believe they are referring to memory leaks. Not really
| a "safety concern" as it will simply cause the
| application to crash (eventually).
| touisteur wrote:
| Erm it is perfectly possible to perform dynamic allocation
| in Ada. You have the 'new' keyword to allocate a new object
| of a type. You have the 'unchecked deallocation' mechanism.
| You have controlled types that deallocate when an object is
| out of scope. You have all sorts of weak references schemes
| in some libraries. You have storage pools to handle
| allocation specifics for a type. You have the secondary
| stack that handles returning objects of unknown-size-at-
| call-site.
|
| Most of those can be disabled though through the
| 'restriction' mechanism (look up Pragma Restriction which
| is very interesting in itself).
|
| SPARK itself can handle and prove some ownership properties
| but to the best of my knowledge isn't at the level of rust
| in memory safety on dynamically allocated memory.
| topdancing wrote:
| > SPARK itself can handle and prove some ownership
| properties but to the best of my knowledge isn't at the
| level of rust in memory safety on dynamically allocated
| memory.
|
| It actually is:
| https://www.adacore.com/uploads/techPapers/Safe-Dynamic-
| Memo...
|
| And using https://www.adacore.com/sparkpro as a reference
| (ignore the 'Pro' bit as it's also available in the GPL
| edition) - anything certified to SPARK Silver level is
| far safer than any Rust code out there.
| pornel wrote:
| Arc in safe Rust won't let you cause use-after-free no
| matter how much you screw up.
| NoZZz wrote:
| Not this echo chamber again.
| generichuman wrote:
| Since when is using SPARK an echo chamber?
| oneplane wrote:
| Someone commented on that page: "Just use Rust, you stupid
| corporate normies." which seems a bit odd considering the
| different goals. The 'big deal' here seems to be formal
| verification, not just "something that is not C" which is what
| people appear to assume here.
|
| Something I suspect they focus on here is the boot ROM or the SEP
| RtOS, which is small enough to warrant this kind of scrutiny.
| [deleted]
| naikrovek wrote:
| commenters like that have turned me off of rust entirely and
| completely.
| throwup wrote:
| So you're avoiding a technology because of unrelated
| teenagers' internet comments. Is that any more useful than
| adopting a technology because of unrelated teenagers'
| internet comments?
| mumblemumble wrote:
| Both are entirely reasonable, especially if it's something
| you're doing in your free time.
|
| Internet toxicity can entirely suck the fun out of
| participating in a community, thereby defeating the purpose
| of participating in it.
|
| But, similarly, a really fun community can do the opposite.
| I used to participate in the Ruby community more for the
| people than anything else. I never actually loved the
| language all that much.
| umanwizard wrote:
| Rust really is a great replacement for C++, despite how
| oversold it is by the more enthusiastic elements of the
| community. I'd recommend trying it out with an open mind.
| api wrote:
| You shouldn't use Linux then. Linux evangelists were far more
| obnoxious when Linux was first making the rounds.
|
| This is just how tech works and how tech people tend to
| behave.
| marginalia_nu wrote:
| Just because people tend to behave in an obnoxious way
| doesn't make it even an ounce more acceptable.
| bitwize wrote:
| Read Aurynn Shaw's essays on "Contempt Culture". Tech
| people can, and need to, change.
| naikrovek wrote:
| that is why I won't use python and why just the mention of
| "Linux desktop" puts a sour taste in my mouth.
|
| feverish advocates _detract_ from the thing they aim to
| augment, and yeah, the worst thing about anything on the
| internet is its community, by a wide margin.
| spillguard wrote:
| > Linux evangelists were far more obnoxious when Linux was
| first making the rounds.
|
| Yes, absolutely.
|
| > This is just how tech works and how tech people tend to
| behave.
|
| I really think that that this old guard mentality needs to
| die out. Rudeness is protected in the industry because we
| normalize that it's... what, intrinsic to programming? But
| that just isn't true, and it's harmful to everyone in the
| field.
| andsoitis wrote:
| > when Linux was first making the rounds
|
| Rust is already 12 years old.
| mrtweetyhack wrote:
| adimineman wrote:
| :/
| TurboHaskal wrote:
| Don't make me remember the Python evangelists back in the
| day when they were targeting Perl.
| naikrovek wrote:
| I remember those fools. those people are why I won't use
| python even today, 20 yrs or so later.
|
| if python was 10% as good as they claimed, it would be
| the most wonderful creation of mankind, past and future,
| by a factor of three.
| Kon-Peki wrote:
| LOL, I can still remember the python "enthusiast" who
| lived across the hall from me in the freshman dorm in
| 1996/97. He is forever etched in my brain.
|
| I ran into him at a bar in Indianapolis 10 years or so
| ago when our alma mater was in the Sweet Sixteen. Must
| have drunkenly passed along my email address.
|
| Because about a year ago, he sent me a link to an
| interview he had given about the new thing he was
| passionate about. I congratulated him and asked a few
| questions out of kindness. Yeah, the response was exactly
| what you could imagine. All future emails from him go
| directly to the trash.
|
| Some people
| mumblemumble wrote:
| I think you're attempting a reductio ad absurdum here, but,
| since your 2nd sentence isn't really true, you haven't
| achieved the "ad absurdum" bit.
|
| Back in the day, yes, the Linux community was indeed quite
| bothersome. That's why I fairly quickly switched to FreeBSD
| as my primary OS. I found I had a lot fewer toxic
| interactions in the FreeBSD community than I did the Linux
| one. In time, FreeBSD didn't really cut it for me any more,
| so I switched to OS X. The Mac community does have its
| incorrigible elements, too, but they are much easier to
| avoid than they are with Linux, where interacting with the
| community is a must in order to get help.
|
| Yes, these things do have implications for open source
| communities. Personally, I suspect that, all along, the
| biggest headwind for Linux on the desktop has actually been
| that the social environment surrounding Linux tends to
| alienate people who might otherwise have stuck around to
| help make it more successful.
| zorgmonkey wrote:
| The timing of their POC being in 2018 makes me wonder if it was
| possibly a direct response to the boot ROM exploit disclosed by
| Kate Temkin in 2018 (https://www.ktemkin.com/faq-fusee-gelee/).
| Traubenfuchs wrote:
| The commentor probably has no idea what a formally verified
| source code is.
| deafpolygon wrote:
| Five years later...
|
| "Welp, back to C because AMD's performance is overtaking ours."
| Raphael_Amiard wrote:
| This is about firmware, nothing to do with the performance of
| GPUs...
| wheybags wrote:
| Firmware and drivers have a massive impact on the performance
| of GPUs. It's not just hardware.
| timbit42 wrote:
| The article states they had no performance hit from
| switching to SPARK.
| sillysaurusx wrote:
| It's rare to see a thread where everyone is
| simultaneously correct but talking past each other.
|
| None of you are mistaken.
| wheybags wrote:
| I noticed this happening and just stopped replying :p
| thatwasunusual wrote:
| This is for _security_.
|
| https://www.slideshare.net/AdaCore/securing-the-future-of-
| sa...
| VHRanger wrote:
| Yes, and security has a large performance impact.
|
| Just look at the performance costs of bounds-checking
| array access in C++ code.
|
| Or more macro, the performance impacs of AV tools or
| Windows Defender on your system
| topdancing wrote:
| > Yes, and security has a large performance impact.
|
| Not necessarily. The linked blog talks about SPARK which
| is about running your code through theorem provers to
| mathematically formally verify that your code does the
| correct thing _in all instances_.
|
| Once you have passed this level of verification - you can
| disable assertions and checks in the release version of
| the application (whilst of course - having the option of
| keeping them enabled in development releases).
| glacia01 wrote:
| >Just look at the performance costs of bounds-checking
| array access in C++ code.
|
| If your compiler can prove you dont need bounds-checking
| it will remove the check and the performance would be the
| same. Hence, if your program has been proven to have no
| runtime errors you dont need them.
| 3a2d29 wrote:
| Wouldn't the performance costs of bounds checking on
| arrays be the same if the computer was doing it or if
| your code was doing it?
|
| By that logic C/C++ doing no bounds checking speeds your
| code up?
| VHRanger wrote:
| Yes, which is why compiling on different optimization
| settings will have bounds checking on or off in C++
| godshatter wrote:
| > Wouldn't the performance costs of bounds checking on
| arrays be the same if the computer was doing it or if
| your code was doing it?
|
| It depends. The C programmer can choose to do the bounds
| checking in a for loop by just checking once before the
| loop begins, or once per iteration even if an array is
| accessed multiple times in the loop, or the safe language
| might have more overhead than a simple if statement in
| the C code. This can, of course, go the opposite
| direction (the safe language has verified the loop
| bounds, but the C programmer is checking before every
| array access). It's a battle between the C programmer and
| the designer and/or implementer of the safe language.
|
| One of the reasons I like C is it gives you more control.
| This can be a good or a bad thing. This can lead to some
| really performant code you couldn't do in most languages
| or it can lead to some gnarly security problems. Maybe
| both in the same spot of code.
|
| I use C to write mostly pet projects at home. I use it at
| work without having a choice in the matter.
| Filligree wrote:
| Well, yes, it does. Whether or not that's a good tradeoff
| is a different question.
| Thaxll wrote:
| AMD drivers are crap though, it's not an old joke it's current,
| for the last 6months AMD drivers are riddle with driver timeout
| ( Timeout Detection and Recovery ), chrome hw acceleration not
| working, bsod, black screen etc ... really that bad.
|
| https://www.reddit.com/r/Amd/comments/xvtn2u/amd_your_driver...
|
| Truth is to have good drivers you need a lot of people and $$$,
| Nvidia has the upper hand on that.
| pizza234 wrote:
| YMMV! As an non-power, graphics-wise, Linux user (that is, no
| 3d), my experience has been better with AMD than Nvidia
| (owned multiple Nvidia cards and a modern AMD one).
|
| In daily usage, I think I've found one issue with the AMD
| card, and a couple with the Nvidia card. What's worrying is
| that when filing bugs while using an Nvidia card, devs both
| times gave the pseudo-automated answer "we can't solve that,
| Nvidia drivers are closed source", which was wrong in one
| case.
|
| In Windows, I've used all the cards for gaming only, and
| never had any issues.
| yamazakiwi wrote:
| Agreed that YMMV, I have heard about these issues in that
| reddit thread about NVIDIA cards as well and have
| experienced the hardware acceleration bug for example.
| dv_dt wrote:
| AMD drivers on Linux have been getting better. Though don't I
| run a bleeding edge card ...
| timbit42 wrote:
| Did you read the article? They said there was no performance
| hit.
| mumblemumble wrote:
| "Did you read the article?" is a _particularly_ unhelpful
| comment when the linked article has been hugged to death, and
| the real article is behind a sign in wall.
| timbit42 wrote:
| I read it using the archive.org link. Should people comment
| without having read the article and knowing what it claims?
| deltasevennine wrote:
| Well sometimes people don't. I know I've done this on
| occasion. Just read the title and dive in with my own
| opinion.
| mumblemumble wrote:
| Yup. I don't think HN can avoid this at scale, though.
| It's been a problem on sites like this since early in the
| days of Slashdot.
|
| The fundamental problem is that the voting and karma
| system actively incentivizes this kind of behavior. No
| amount of "did you read the article?" comments can
| counteract that force. All they do is increase the noise
| level even further.
| Dylan16807 wrote:
| Are you kidding? Asking if people read the article is
| _more_ helpful when there 's an unusually large number of
| people that haven't.
|
| And if they need help accessing it, help can be arranged.
| 0rzech wrote:
| > "Did you read the article?" is a particularly _unhelpful_
| comment when the linked article has been hugged to death,
| and the real article is behind a sign in wall.
|
| As is making assumptious comment without reading the
| article, especially when the comment may be wrong. I think
| it's not only unhelpful, but actually harmful, because
| other people, who also jump straight to comment section,
| may form an opinion based on misinformation. Also, timbit42
| did provide us with what they read in the linked content;
| unless they added it with an edit.
| mama_scorpion wrote:
| Ada/SPARK is a strong typed C with visibility done correctly.
| (you know the "private" notion in C++ ... and sane scoping
| using semantic grade packages) All checks in Ada/SPARK can be
| removed so essentially you end up, in production, with code as
| performant as C.
| aidenn0 wrote:
| This is only true if your C code is as correct as your
| Ada/SPARK code. Incorrect software can run faster than
| correct software...
| mama_scorpion wrote:
| So true! A loop that crash at the first iteration of a
| zillion is quick as electricity in a NOR gate.
| touisteur wrote:
| I'm following the work of the rust compiler team these days,
| they're trying to leverage all rust frontend guarantees to
| perform better optimisations.
| 0xbadcafebee wrote:
| This is literally a PR article from a company who sells SPARK
| products, talking about a company buying into SPARK. Please
| provide your own salt lick.
| nix23 wrote:
| I absolutely love AdaCore, last employer (~6 years ago) worked
| heavily with Ada and AdaCore, the support from them was just
| mind-blowing, sounds like a advertisement i know, but not often
| have i seen something like it..well maybe from SGI and
| DEC..longlong time ago.
| Keyframe wrote:
| I like my Rust and furries as the saying goes, but Ada is the
| underrated language out there. It really has a lot of things
| doing well for it, is really nice to write shit in it and
| probably the AdaCore being a single entity behind modern chain
| is what's both good and bad behind it. Yes, GNAT.. but, same
| thing.
| uri4 wrote:
| > last employer (~6 years ago
|
| It does not sounds like ad, but like Fortran. Last Ada job I
| remember was mars rover in 90ties. Great but nothing for new
| hires!
| manv1 wrote:
| "What if you just stopped writing bad code?"
|
| "What if you used static analyzers to detect these issues before
| shipping?"
|
| "What if you put bounds checking into your functions to prevent
| this?"
|
| "What if you tested your software more effectively before
| shipping it?"
| tialaramex wrote:
| > What if you just stopped writing bad code?
|
| This is a popular but useless question. The reality is that to
| err is human. At scale it's even worse because now you're not
| just accepting that you personally may be capable of mistakes
| when writing software, you might have made a mistake when
| hiring the people who in turn hire the programmers. Ouch.
|
| > What if you used static analyzers to detect these issues
| before shipping?
|
| In principle all the modern safer languages are in some sense
| is more static analysis. But the analysis is made possible in
| considerable measure through language design. If you insist on
| an unsafe language (like C or C++) then the analyser can't help
| much beyond "Don't use this language". Good advice.
|
| > What if you put bounds checking into your functions to
| prevent this?
|
| Bounds checks are a very small part of the problem. They're
| symptomatic (a language designed to do well at this will
| enforce bounds by one means or another) but not sufficient.
|
| > What if you tested your software more effectively before
| shipping it?
|
| You can't afford to actually test software thoroughly by its
| nature. You will only be able to test a microscopic fraction of
| possible system states, whether the softwawre works as intended
| under all the many other states remains unknown.
| kristianp wrote:
| They don't actually mention what SPARK is nor link to any product
| page. Not very useful self-promotion.
| bullen wrote:
| I'm dreaming of a C with only pointers that has an optional VM
| (with and without GC) and namespaces, string and stream included.
|
| You can cook your own (C++, WASM and Java), but if it was
| standardized and cross compatible.
|
| Also curious why so many dislike streams?
| pjmlp wrote:
| Have a look at D.
| bullen wrote:
| https://en.wikipedia.org/wiki/List_of_programming_languages
|
| I think I'm not going to like it because I want something
| that is foundational = works everywhere, is stable everywhere
| and has all features everywhere (f.ex linux 32-bit on ARM)
|
| But I will give it a fair shoot.
| cweagans wrote:
| LDC is a frontend to LLVM. https://github.com/ldc-
| developers/ldc
| pjmlp wrote:
| As addendum, GDC is part of GCC on the other side.
|
| So already plenty of platforms are already covered.
| vitaminCPP wrote:
| At the moment, Zig and Rust are the most exciting places to
| look, IMO.
| alcover wrote:
| > C with only pointers
|
| Interested in what you meant by that.
| didip wrote:
| He probably doesn't want pointer arithmetic.
| bullen wrote:
| I don't want to add/remove &, * and sometimes *& everywhere
| until it compiles... I don't care about memory in that way.
| cookiengineer wrote:
| Aren't you describing golang?
|
| Golang is basically C with pointers, and still very very static
| in its programming paradigms.
| [deleted]
| samanator wrote:
| Golang only has a GC, it doesn't have an option to manage
| memory in other ways.
|
| Were you referring to unsafe pointers and calls to Cgo?
| cookiengineer wrote:
| > Golang only has a GC, it doesn't have an option to manage
| memory in other ways.
|
| But as far as I understand golang's memory internals, they
| still offer you to use the copy-based stack directly ("var
| some SomeStruct;") or to allocate things directly on the
| heap (via "new(SomeStruct) / make(SomeStruct)".
|
| I might be wrong about this, but this is what I understood
| from casually reading the spec [1]; while they never
| mention stack or heap specifically and describe it more as
| memory being allocated at run time, which kind of hints to
| a copying garbage collector underneath. But they also seem
| to implement a mark and sweep mechanism [2] so I'd say it's
| a hybrid GC, similar to how ECMAScript VMs work these days.
|
| Nevertheless you're right with the argument that it doesn't
| offer a way to manage memory yourself, which I think is a
| good thing. Technically you could use "C.malloc()" and
| "C.free()" though.
|
| > Were you referring to unsafe pointers and calls to Cgo?
|
| Yeah, I was kind of referring to the possibility to
| implement C-interface adapters using CGO (the internal "C"
| and "unsafe" packages). Personally I would only use C APIs
| if there's no way around them, though, and keep as much
| code in golang as possible.
|
| [1] https://go.dev/ref/spec#Allocation
|
| [2] https://github.com/golang/go/blob/master/src/runtime/mg
| c.go#...
| wyldfire wrote:
| > I'm dreaming of a C with only pointers that has an optional
| VM (with and without GC) and namespaces, string and stream
| included.
|
| It'd be really nice to be able to trigger some scope-exit
| behavior, too, IMO.
| bullen wrote:
| Do you mean for Exception handling?
| alcover wrote:
| Maybe parent hinted at what GCC extensions like
| ___cleanup__ variable attribute_ do.
| wyldfire wrote:
| Indeed: maybe not a full "RAII" kind of feature but at
| least something simple that allows the author to specify
| (around the same place where a resource allocation
| happened, e.g.) that some other symmetric behavior should
| take place on any scope exit point.
| bullen wrote:
| Hm, ok my take on this is unexperienced; I come from Java
| and only learned C++ recently: I would like to have heap
| inspection tools which a VM would give you. Then you can
| remove the VM if/when you need performance and have
| profiled memory enough.
| sim7c00 wrote:
| redtriumph wrote:
| Getting a 504 when I click the link. Is anyone seeing this issue?
| LargoLasskhyfv wrote:
| Yes. OpenResty needs some rest. Give it time. 2 minutes, or so,
| after a click on reload.
| throw0101a wrote:
| "Be the change change you wish to see in the world." -- Arleen
| Lorrance+
|
| + No Gandhi: https://quoteinvestigator.com/2017/10/23/be-change/
| rectang wrote:
| I enjoyed reading this quoteinvestigator article, but the
| conclusion it reaches credits Arleen Lorrance:
|
| > _In conclusion, Mohandas Gandhi did write a pertinent passage
| in 1913 that expressed a similar idea, but the popular modern
| saying is considerably more concise and forceful. QI believes
| Arleen Lorrance should receive credit for the expression she
| wrote in 1974._
| [deleted]
| stephc_int13 wrote:
| Ada is the better Rust :)
|
| I know the approach is not the same, but the goals are similar
| enough. And I think that Ada core principles are more useful and
| less "magical" for hardening code.
| mumblemumble wrote:
| Perhaps more to the point, it sounds like SPARK is better
| suited to this particular use case. Some of the problems
| they're using SPARK to solve aren't even on Rust's radar.
| CivBase wrote:
| I would actually really love Ada if it weren't for a couple
| extremely frustrating syntax decisions: using parentheses for
| both call arguments and array subscripts, and making
| parentheses optional for calls with no arguments. Those two
| decisions make it incredibly difficult to distinguish between
| function calls, variables, and array subscripts. I absolutely
| _have_ to use an IDE for Ada as a result. Also,
| Title_Case_With_Underscores is just silly.
|
| Otherwise, I agree. Ada is pretty great. It deserves more love.
| hox007 wrote:
| Both decisions to use parentheses for both arrays and
| argument lists and omitting parentheses for call with
| arguments come from Ada's design goals of supporting
| programming at large. While this is contrary to some other
| languages that focus on specifics of implementation, the
| decision isolated design intent from implementation details.
|
| The original "Rationale for the Ada programming language"
| book provides a lengthier discussion on these points.
|
| TLDR; The syntax is an intentional language design choice
| which puts capture of design intent in the forefront over
| implementation details.
| CivBase wrote:
| That's all well and good but whatever the rationale it
| still makes code unnecessarily hard to read.
| A := B; X := Y(Z);
|
| Is B a variable name or a function call? Is Y a function or
| an array? Is Z itself a function call? There is no way to
| know the answers without looking up the definitions for B,
| Y, and Z. And the answers are important because function
| calls can alter the program state and affect performance in
| ways that a variable deference or array subscript cannot.
|
| So when reading Ada code, a developer has to constantly
| jump around the code base to understand which fundamental
| language mechanics are being used. It's a frustrating
| problem for someone who has to review real-time, safety-
| critical Ada code. And I've never run into that problem
| with any other language.
| renox wrote:
| There's the same issue with C++ vs C: C++ is better for
| 'programming in large codebase ' because it can
| hide/encapsulate more things.
|
| But that makes C++ worse for hard real time programming
| where you want to know what's happening.
| docandrew wrote:
| With more descriptive variable names it's not really a
| problem in practice. If B and Y contain verbs, they're
| probably procedure/function calls.
| ibiza wrote:
| Is there potential for a Erlang -> Elixir play here? Ada ->
| Grace :). I find it a shame languages w/ a Pascal lineage are
| unpopular simply for syntactic reasons.
| sroussey wrote:
| When I used Ada the IDE was vim. LoL.
|
| Actually, I wrote an optimizing compiler for Ada in C++. Also
| in vim.
| acomjean wrote:
| Consider the source. Its Adacore, the support open source Ada. I
| know them from the Ada on x86 seminar they held at my employer
| (we were using Ada on PA-RISC). Nice people but pro Ada (or its
| "Spark" language which I guess is like Ada).
|
| But another huge issue is that C is the language used by the OS.
| If you want to use that OS functionality to allocate memory, do
| networking, IPC etc, you are using a C header file and calling
| into it. We had a binding library to making calling C from Ada
| easier, but its still an extra step. The good news is that other
| languages are starting to have some great libraries.
|
| Ada and Rust and a bunch of other languages are safer than C, and
| likely a better choice. Its just there is a lot of existing code
| to port over.
| UltraViolence wrote:
| They talk about SPARK, but I never heard about it until now.
| Reading up on Wikipedia it seems an ADA derivative.
|
| I assumed they were switching to Rust, but that doesn't seem to
| be the case.
| Raphael_Amiard wrote:
| SPARK allows you to formally prove that your code is correct
| according to a given specification. It can thus provides much
| stronger guarantees than what Rust would be able to provide.
|
| Similar technology exists for Rust, but it is much less
| advanced than SPARK is (https://github.com/xldenis/creusot)
| leoh wrote:
| I'll never forget this neckbeard older dude in an algorithms
| course with me in College
|
| "C is the only good language. And you should use it for
| everything."
|
| "Even web servers that power apps?"
|
| "How could you consider anything else?"
|
| During the same program (over ten years ago), someone came from
| Adobe and basically said "C/C++ are the source of the majority of
| our security bugs and would just go away with another language."
|
| Change is hard folks
| ilyt wrote:
| I wouldn't believe Adobe, company known for shit security
| practices for decades now, to be any authority on the subject.
| They'd cut themselves with safety scissors
| leoh wrote:
| They wouldn't, but this was a pretty bright staff scientist
| iirc.
___________________________________________________________________
(page generated 2022-11-07 23:02 UTC)