"The idea that a young teen has a right to privacy online is a joke" - <AUTHOR> http://www.facebook.com/tommyjordaniii/posts/10150541114050846

<comment><AUTHOR> _Anyway, I know my children's online history. I can see every word she's ever typed, every keystroke she's ever sent across her laptop, regardless of whether she was at home or at a friend's house.

If my daughter were to leave school in the middle of the day for any reason, as soon as her cell phone's GPS footprint triggered outside the normal 3 mile radius she's supposed to be in I get a text alert. (whether someone thinks they're smart enough to disable the gps or not) Then I can push a few buttons and turn on her phone's speaker, track her GPS location in real-time. I make it a point to know how to get to my child better than any police could dream of in this day and age. Nothing short of an FBI swat team find my child better than I can. I could make a call to 911 and tell the police turn-by-turn directions to where she was within about 500 feet. I can do the same with her laptop. I can remote activate the web camera, track the ISP node the laptop is closest to - within about one mile and constantly record what happens on the screen if I need to. Call me over-protective if you want, but I know what the technological capabilities of the bad people are because we use them too in our industry, though for different purposes._

Is he just bragging or are all these SOP in this line of business?

<comment><USER2> Don't know if he's bragging or not but all that technology is useless. If she didn't want to be tracked or if bad guys got her that didn't want to be tracked they sure as hell wouldn't be lugging all that highly trackable technology as well.

Geez, anybody who watches TV or movie thrillers knows this by now.

<comment><USER3> Easier to just leave the phone in the classroom and go watch the movie or hangout with friends. And by the time the classes are over, come pick it up and go back home as usual. The dad thinks the daughter is at school.

</comment></comment></comment><comment><USER4> Background:

[http://blogs.canada.com/2012/02/15/facebook-dad-says-hed- sho...](http://blogs.canada.com/2012/02/15/facebook-dad-says-hed-shoot-his- daughters-laptop-again/)</comment>


Hacker Forces DigiNotar Into Bankruptcy   - <AUTHOR> http://www.securityweek.com/hacker-forces-diginotar-bankruptcy

<comment><USER2> Sounds to me like DigiNotar forced itself into Bankruptcy. Over the long term, getting hacked seems unavoidable. However, poor responses to getting hacked are completely avoidable.</comment>


A Very Quick Comparison of Popular Languages for Teaching Computer Programming - <AUTHOR> http://www.ariel.com.au/a/teaching-programming.html

<comment><USER2> I used to think: _C is a horrible language for beginners, they should learn python due to its simplicity. This will allow them to learn about control structures and program flow in a simple and easy to read environment_. But the more I think about it, the more I like C. It gives you the best understanding of what computations are actually being done by your processor; the mental exercises involved with fulling understanding pointers is valuable at the collegiate level (much less so if your learning to program on your own, I believe college is a time to increase your analytical abilities rather than just learn raw facts); It also has the simplest syntax to learn (for a procedural language).

You dont have to explain argv, argc or the details of scanf to beginners. Thats like saying python is complex because you need to explain iterators and generators. You don't need to dig that deep into the language as a beginner, you just need to be able to understand the structure, control flow and be able to get your programs working.

<comment><USER3> > But the more I think about it, the more I like C. It gives you the best > understanding of what computations are actually being done by your processor

Yes, because C is exactly how computers work inside! SO CLOSE TO THE METAL

> the mental exercises involved with fulling understanding pointers is > valuable at the collegiate level

I have learnt about mappings in mathematics in kindergarten. Literally. Then in university we have had exactly one sentence to flesh out the idea in ZFC. You really think C is so mind bending?

<comment><USER4> I believe it is quite close to the metal. When I had my Systems Programming course in first year of college we started with C, and then continued with x86 assembly. One of interesting parts was, when we compiled our C code to assembly and then compared with our hand-written assembly code. Was fun :)

<comment><USER3> Do you realize that with pipelining, preemptive computation, multiple levels of caching, opcode optimization, NUMA, massive parallelism, and all that other stuff x86 is to hardware what Java is to hardware interrupts?

Answer: you don't because otherwise you would not have posted the above.

<comment><USER2> You're over exaggerating. You can teach students about processor theory, assembly language and C without getting into all the extra stuff.

All the extra stuff is built on that foundation, and learning C helps you understand that foundation better than any other language.

<comment><USER3> This is not "extra stuff". It is _how it works_. x86 was made to be simple to hand-code, not to in any way reflect the hardware. And then, decades later, new developments to it are so that it's _easy to compile to_. The language went through two major paradigms without either having the point of x86 reflecting the hardware it abstracts. SIMD, NUMA, pipelining and caching is exactly how processors work right now. And they're radically different to what happened before the Intel Core family of processors. This is in turn radically different to what happened before the Pentium Pro family of processors. Yet all support the same x86 instruction set. The corollary is that x86 is an abstraction. You're being ignorant if you think x86 is like the opcodes being executed after the whole caching stage has happened.

</comment></comment></comment></comment></comment></comment><comment><USER5> Erlang version (abc.erl):

        -module(abc).
        -export([main/0]).
        main() ->
            {ok,[A]} = io:fread("A=?","~f"),
            {ok,[B]} = io:fread("B=?","~f"),
            C = A + B,
            io:format("C=~f~n",[C]).

or

        -module(abc).
        -export([main/0]).
        main() ->
            {ok,[A,B]} = io:fread("A,B? ","~f ~f"),
            C = A + B,
            io:format("C=~f~n",[C]).

Compile and run from REPL:

        c(abc).
        abc:main().

Or just execute in REPL:

        {ok,[A]} = io:fread("A=?","~f").
        {ok,[B]} = io:fread("B=?","~f").
        C = A + B.
        io:format("C=~f~n",[C]).

</comment><comment><USER6> Was anyone else initially confused by the 'Postscript' heading at the bottom? At first I thought it referred to the programming language (PostScript) but in fact it's just referring to the "writing after the writing" (P.S.).

</comment><comment><USER7> His postscript is a debatable improvement, as input() in Python 2.x (which was what the article was written using) actually evaluates the input as a Python expression before storing it. It's equivalent to wrapping the input functions that the other languages use in eval(), which is (imo) a very, very bad practice to teach unless you're asking your students to write a REPL.

<comment><USER8> Yes, he should have been using raw_input().

</comment></comment><comment><USER9> This was a very interesting read, but the Python code sample was painfully out of date. It might be worth it to create a modernized version of this post, with updated code samples for all the languages included, and additionally adding newer languages like Ruby and JavaScript.

</comment><comment><USER10> > I spent about 15 minutes, failed, then searched Google for an example.

It is understandable that Java can be verbose, but 15 minutes followed by failure, make the author seem almost clueless about Java.

<comment><USER11> yeah, the use of java.util.Scanner would make it _much_ more succinct:

        import java.util.Scanner;

        public class Addup {
            public static void main(String args[]) {
                Scanner sc = new Scanner(System.in);
                int i1 = sc.nextInt();
                int i2 = sc.nextInt();
                System.out.println(i1 + i2);
            }
        }

<comment><USER12> Very interesting, although he does indeed say:

> The extensive class library is however quite daunting. It appears there's a > class for almost everything, and much of "programming in Java" seems to > consist of "searching for the right class". Even after two years I find I > cannot do much in Java without constant reference to the documentation.

</comment></comment></comment><comment><USER13> This is old, and there are no mentions of Erlang, Haskell or Scheme.

Not even PHP which while it isn't perfect it's still pretty easy to learn.

</comment><comment><USER14> In the Java example there is a ton of error checking that is not being done in the other examples. Not really a fair comparison. The author said the programs should complete the task of "reading two numbers from the user, adding them together and printing out the result." The Java program does more than that, so of course it looks more verbose.

<comment><USER15> I think it _is_ a fair example: both NumberFormatException and IOException are checked exceptions, so the code will fail to compile if they're not caught.

<comment><USER16> Despite being checked, they do not necessarily have to be caught if you add a `throws` clause in the method declaration.

</comment></comment></comment><comment><USER17> Surprised to see Scheme was not included.

</comment><comment><USER3> To everyone who was interested by pg's idea of a simple language for parallelism, check out pi calculus: [http://mainisusuallyafunction.blogspot.com/2011/09/lambda- to...](http://mainisusuallyafunction.blogspot.com/2011/09/lambda-to-pi.html)</comment>


Rhythmbox 3.0 Has Been Officially Released - <AUTHOR> http://news.softpedia.com/news/Rhythmbox-3-0-Has-Been-Officially-Released-380596.shtml

<comment><AUTHOR> Finally! Yeah baby :D</comment>


FiveThirtyEight's World Cup Predictions - <AUTHOR> http://fivethirtyeight.com/interactives/world-cup/

<comment><AUTHOR> And here's the link to some discussion of their model in case you miss it.

[http://fivethirtyeight.com/features/its-brazils-world-cup- to...](http://fivethirtyeight.com/features/its-brazils-world-cup-to-lose/)</comment>


Linus Torvalds goes off on Linux and Git - <AUTHOR> http://typicalprogrammer.com/?p=143

<comment><USER2> SATIRE folks... satire. There's a tag to that effect at the top of the post.

</comment><comment><USER3>
        I have a text editor I've been using myself that is so complicated it makes VIM look like Notepad — maybe I'll release that.

This is interesting. Has Linus talk more about this editor he is using? Maybe if he releases it, the editor will be the new trend he's talking about :D

<comment><USER4> Linus uses MicroEMACS. This post is satire.

</comment></comment><comment><USER5> Imho, it does not sound like it's Torvalds. I've never seen him talking about node or rails or any other web technology.

<comment><USER6> It's tagged as "satire" (immediately below the title).

<comment><USER7> I guess it was good in that it had me going, but the cynicism really made me sad until I realized it wasn't real.

</comment></comment></comment><comment><USER8> A user once told me my product had no geek cred because it was too easy to use.

</comment><comment><USER9> Reminds me of: <http://joelrunyon.com/two3/an-unexpected-ass-kicking>

</comment><comment><USER10> It sounds quite strange, as martius mentioned Torvalds doesn't speak of other technologies and he is known for using a custom version of MicroEmacs

</comment><comment><USER11> You can tell in the first line it's a joke.</comment>


Go generate: Proposal for Go 1.4 - <AUTHOR> https://docs.google.com/a/golang.org/document/d/1V03LUfjSADDooDMhe-_K59EgpTEm3V8uvQRuNMAEnjg/edit?pli=1

<comment><USER2> »the author commits the generated files to the source repository, so that they are available to clients that use go get:«

I understand that they want to keep $ go get fast, but i think that it is a bad practice to commit generate files into a repository. Instead, $ go get should call go generate.</comment>


The Next Gold Rush Will Be Under the Sea - <AUTHOR> http://motherboard.vice.com/read/deep-sea-gold-rush <comment><USER2> we need to price this shit in to the goddamn market, having random unpriced externalities that can just be captured by whatever the base cost to obtain them, is reckless.

Not only is it not an equitable way to disperse resources, but there is an incentive to just absolutely destroy another key piece of the environment. I am not some tree hugging greenie either, not there would be anything wrong with that, but dispatching remote control bulldozers underwater in droves is going to be a great way to ruin an ocean that already has significant problems.

<comment><USER3> I know I'm nitpicking, and I'm just using your phrase as an example, but it always surprise me how often we exclude ourselves for being green behind an utilitarian argument. I mean, is that a terrible thing? I don't hear often, "I'm not a business shark, but I guess this business should be profitable".

<comment><USER4> I consider myself a pretty green person, but I have use the same language as the parent. The reason is because it prevents somebody from jumping to the anti green approach and calling or assuming you're a tree hugger. This way when you state that you aren't a tree hugger but still support a particular argument, it makes them weigh the argument in a reasonable way instead of going on the defensive right away. So it changes the logic from "I'm not a tree hugger, screw your point and ideals" to "I'm not a tree hugger but neither is this guy so his point may be reasonable, let me actually listen to this argument and see". It's a smoke rewording to get a person to be more receptive. (Typed on phone, hope it made sense)

</comment></comment></comment><comment><USER5> I keep wondering why we don't mine garbage landfills. Surely somewhere the technology exists to turn all that waste into raw materials again.

<comment><USER6> Well, on a fundamental level, if energy were cheap enough you could just vaporize the stuff and condense it out as pure elements, so it's not really a technology problem per se. It's an economic problem.

</comment></comment><comment><USER7> Is it not enough that many great land species are extinct that they now want to destroy ocean life?

I wish I were powerful enough to do something to stop this.

</comment><comment><USER8> Like we haven't heard that before...

[https://en.wikipedia.org/wiki/Project_Azorian](https://en.wikipedia.org/wiki/Project_Azorian)

</comment><comment><USER9> Underwater diamond mining already exists. Mighty Ships did an episode about it: [http://www.smithsonianchannel.com/shows/mighty- ships/peace-i...](http://www.smithsonianchannel.com/shows/mighty-ships/peace- in-africa/809/3399768)

</comment><comment><USER10> Proteus IV always hated this idea and I have to agree. Man can do too much damage under the sea. Imagine the open pit mines and their pollution able to directly contaminate the water.

</comment><comment><USER11> What about bitcoin ? :P

</comment><comment><USER12> Yeah, let's disturb the sea floor, what could possibly go wrong?

<comment><USER13> Clathrate gun hypothesis: [https://en.wikipedia.org/wiki/Clathrate_gun_hypothesis](https://en.wikipedia.org/wiki/Clathrate_gun_hypothesis)</comment></comment>


Bill Gates slams 'shocking' U.S. response to Covid-19 pandemic - <AUTHOR> https://www.statnews.com/2020/09/14/bill-gates-slams-mismanaged-u-s-response-to-covid-19-pandemic/ <comment><USER2> I appreciate a lot of Gates' statements here, since they are substantive and not just posturing. The issue is that the US medical system is rotten to the core. There are hundreds of thousands of wonderful individual practitioners and even thousands of excellent teams, but the system as a whole is broken.

His idea that no one should be paid for a test result if it takes more than 24 hours to result is not bad, but the existing system is not set up for it. Decades of regulation of all aspects of the US medical system, from billing codes even to electronic health records, would prevent that kind of change from being adopted overnight. If we adopted this change, you'd very likely see almost no one running any COVID tests at all - the risk and infrastructure investment would be too high, for too little payout. (Recouping the cost of lab tests is generally hard as is, since the costs of running a medical lab are almost entirely fixed, both in terms of labor and capital. Routine maintenance must be performed, the lab must have a certain contingent on duty to handle stat tests, etc.)

I'm not sure the US system can be improved unless we have some practitioners who want to make a clean break from the existing regime, and they get some cover from the government to actually innovate. I'm not holding my breath.

<comment><USER3> > If we adopted this change, you'd very likely see almost no one running any > COVID tests at all

This is especially true for providers who aren't running the tests in-house. If your doctor takes a test and sends it out to an external lab like LabCorp, who is responsible if the complete process takes more than 24 hours?

In reality, your doctor would simply stop testing for Coronavirus and instead refer you to a LabCorp collection center, where they could keep you waiting in line until they had enough testing capacity to take your sample and start the 24-hour clock. Everyone loses.

Not to mention all of effort required to retool billing and accounting systems to account for time-based costing. This alone would drive the cost of testing upward by huge amounts. Or more realistically, providers would simply not offer tests unless patients paid in cash to avoid this mess.

This is a great example of how regulation can end up making the situation worse, despite good intentions.

<comment><USER4> Im currently in grand teton national park and need to get a test before seeing my parents. This area that has 5+ million visitors a summer has about 3 covid tedting sites in an 2-3 hour drive. The main hospital needs a referal to give you s test. Any referals from out of the area will have their tests sent to another site, results are expected in 5-7 buisness days. When asked how much it would cost, they said they have no idea, they will bill the insurance. We have decided not to take this test and wait till we are in a major city and get the 15 minute test. Naturally, they have plenty of open appointments to administer the test. Our healthcare is completely broken. These national parks are intersections of people from all over the US and one of the most important places to have rapid testing and its just completely unavailable.

<comment><USER5> Imagine a virus so bad you got to get tested in order to know if you have it or not. You made the choice to go to the park nobody forced you to go there you're going to have to sacrifice some stuff if you want to be 100% safe but trust me buddy CDC websites says 003% that anything is going to happen

<comment><USER4> Thankfully, I'm a young and healthy adult and wish to do my part to continue living my life while doing due diligence to protect more susceptible people around me. And if you want to look at it in a fiscally conservative way, prevention of spread is cheaper than treating those it may have spread to.

</comment></comment></comment></comment></comment><comment><USER6> I don't know when this interview was, but I'm surprised to see no mention of sputum testing as a replacement for Nasopharyngeal RT-PCR.

I don't know the precise number, but probably at least a dozen of these spit tests have been developed at Universities and approved by the FDA for emergency use. Some even use the LAMP protocol as opposed to RT-PCR, which saves on time and reagents.

Another thing I always think of is how we didn't adopt the contact tracing protocol that Google and Apple developed. Obviously it was a trust issue, and maybe some logistical shortcomings, but contact tracing as we've implemented it is largely ineffectual in reducing spread. The serial interval in young people is likely less than the time it takes to get back a test, and certainly shorter than the time it takes to get a test and complete a contact tracing interview.

The US response to Covid is obviously a polarizing issue, but we're all wrong to assume that we couldn't have done better.

</comment><comment><USER7> At this moment of history he is standing up and saying things government don't want to hear. I really respect the patriotism and courage of Gates.

</comment><comment><USER8> If the US had done nothing, many models predicted over 2 million deaths by now.

We have had 200k, so a 90% reduction.

Hopefully there is a vaccine soon

<comment><USER9> > many models predicted over 2 million deaths by now

citation needed.

Here are many models that we can backcheck: [https://projects.fivethirtyeight.com/covid- forecasts/](https://projects.fivethirtyeight.com/covid-forecasts/)

<comment><USER10> > without action by the government and individuals to slow the spread of > coronavirus and suppress new cases, 2.2 million people in the United States > could die

[https://www.nytimes.com/2020/03/16/us/coronavirus- fatality-r...](https://www.nytimes.com/2020/03/16/us/coronavirus-fatality- rate-white-house.html)

</comment></comment></comment><comment><USER11> Whenever I read such extreme action verbs as "slam", "bash" etc. in a headline, I have to assume the underlying article is a populist piece of garbage.

<comment><USER5> this whole place is turned into Reddit man there's people up top in this comment section complaining that there's not enough testing while they're frolicking around the countryside. Complaining that they want free testing. Imagine a virus so bad you have to get tested to know if you have it or not

<comment><USER12> What do you mean when you say this place has "turned into reddit"? Are you referring to the generally lower standard of comment quality there? If so, that's ironic.

Imagine a virus so unpredictable that you might take anywhere from 0 to 14 days to become infectious, and you could end up anyhwere from unknowingly and asymptomatically shedding the virus to dead from it. Imagine that.

</comment></comment></comment><comment><USER13> Here's is an interesting article on the relationship between Bill Gates and the media recently published by CJR:

Journalism's Gates keepers: [https://www.cjr.org/criticism/gates-foundation- journalism-fu...](https://www.cjr.org/criticism/gates-foundation-journalism- funding.php)

If you are wondering why someone like Michael Levitt [1] doesn't get wall to wall coverage by media (including outfits like RT) [as an 'expert voice on pandemic response'], the above article has a few clues.

[1]: He's just one example. There are many others.

[https://twitter.com/mlevitt_np2013?lang=en](https://twitter.com/mlevitt_np2013?lang=en)

[https://en.wikipedia.org/wiki/Michael_Levitt](https://en.wikipedia.org/wiki/Michael_Levitt)

\-- p.s. relevant pull quote asking the timely question --

 _During the pandemic, news outlets have widely looked to Bill Gates as a public health expert on covid—even though Gates has no medical training and is not a public official. PolitiFact and USA Today (run by the Poynter Institute and Gannett, respectively—both of which have received funds from the Gates Foundation) have even used their fact-checking platforms to defend Gates from "false conspiracy theories" and "misinformation," like the idea that the foundation has financial investments in companies developing covid vaccines and therapies. In fact, the foundation's website and most recent tax forms clearly show investments in such companies, including Gilead and CureVac._

<comment><USER14> Michael Levitt, though almost certainly a smart guy, has not had the best track record, making predictions both accurate and not. Also, predictions alone are...not that useful? From your Wikipedia article:

> In March, the Los Angeles Times reported that Levitt correctly forecasted in > February that the COVID-19 pandemic in China would soon peak and that China > would end up with around 80,000 cases and 3,250 deaths from COVID-19.[41] > However, it has been noted that Levitt actually made a number of > predictions, including incorrect forecasts, in February about China's > COVID-19 trajectory[42], including one on February 7, 2020 claiming that "by > 14-Feb. we will have reached 95% of the eventual death count of 928".[43] > Levitt also has stated his belief that achieving natural herd immunity to > the virus is possible[44] and has spoken against lockdown orders.[45]

> Levitt also wrongly predicted that Israel would suffer no more than 10 > COVID-19 deaths[46]. On July 25, 2020, Levitt predicted that COVID-19 in the > United States would be over "in 4 weeks with total reported deaths below > 170,000".[47] However, this prediction about the reported death count also > ended up being wrong as the number of reported deaths from COVID-19 in the > United States exceeded 170,000 on August 16, 2020, only 3 weeks after > Levitt's prediction.[48]

Sounds like he does get some coverage. As for why it's not wall-to-wall? Maybe his predictions have been wrong too many times?

<comment><USER13> Don't focus on one guy. He is just one example. There is a pattern of a whole range of individuals with very credible credentials that are entirely ignored.

Track records don't seem to matter. The famous Imperial College model was by a worker with a rather alarming track record. How is the track record of Bill and Melinda Gates foundation, btw? Or the unqualified man currently serving as head of WHO? His C.V. is alarming enough.

So side arguments aside, the question remains as to why Bill Gates, are granted such a global megaphone. The article from Columbia Review of Journalism tells us why that may be the case.

I find it entirely irrational and unreasonable that decisions that will affect the entirety of humanity today, and will definitively alter the course of human development are to be made by individuals such as Bill Gates, and that other input by far more qualified individuals is entirely ignored, if not blackwashed.

It not unreasonable to seek a second opinion even for relatively minor health matters. And here we are talking about metaphorical open heart surgery on the very nature of society: how we are governed, how we interact, and how we make collective decisions.

There has never been a more timely moment to ASK QUESTIONS.</comment></comment></comment>


Why Companies Aren't Getting the Employees They Need - <AUTHOR> http://online.wsj.com/article/SB10001424052970204422404576596630897409182.html

<comment><USER2> >Some of the complaints about skill shortages boil down to the fact that employers can't get candidates to accept jobs at the wages offered. That's an affordability problem, not a skill shortage. A real shortage means not being able to find appropriate candidates at market-clearing wages.

ay, there's the rub.

A few weeks ago I was considering offers from two companies, in totally different industries. One was a non-profit in International Accreditation in the Health Industry, and the other was in Finance.

The IA company ended up submitting a significantly higher offer than the finance company. Correspondence with them made it appear to be just a game of numbers for the finance company - what kind of skill they could get, for how cheap they could get it.</comment>


Microsoft Acquires Surface 3 Pen Tech from N-trig - <AUTHOR> http://techcrunch.com/2015/05/01/microsoft-acquires-surface-3-pen-tech-from-n-trig/

<comment><USER2> as a surface 3 owner, I want to say that the pen is a disaster. I won't buy it again.

the don't let you to configure the pen's buttons ...</comment>


Sarcasm is easy-as-pie, modern, blazingly fast JavaScript library - <AUTHOR> https://github.com/komlev/sarcasm <comment><USER2> Expected something. Got that thing. Did not disappoint.</comment>


Conflating pointers with arrays: C's biggest mistake? (2009) - <AUTHOR> https://www.digitalmars.com/articles/b44.html <comment><USER2> This is IMHO by far NOT C' biggest mistake. Not even close. A typical compiler will even warn you when you do something stupid with arrays in function definitions (-Wsizeof-array-argument is the default nowadays).

On the other hand, UBE (undefined, or unspecified behavior) are probably the nastiest stuff that can bite you in C.

I have been programming in C for a very, very long time, and I am still getting hit by UBE time to time, because, eh, you tend to forget "this case".

Last time, it took me a while to realize the bug in the following code snippet from a colleague (not the actual code, but the idea is there):

struct ip_weight { in_addr_t ip; uint64_t weight; };

const struct ip_weight ipw1 = {0x7F000001, 1}; const struct ip_weight ipw2 = {0x7F000001, 1};

const uint32_t hash1 = hash_function(&ipw1, sizeof(ipw1)); const uint32_t hash2 = hash_function(&ipw2, sizeof(ipw2));

The bug: hash1 and hash2 are not the same. For those who are fluent in C UBE, this is obvious, and you'll probably smile. But even for veterans, you tend to miss that after a long day of work.

This, my friends, is part of the real mistakes in C: leaving too many UBE. The result is coding in a minefield.

[You probably found the bug, right ? If not: the obvious issue is that 'struct ip_weight' needs padding for the second field. And while all omitted fields are by the standard initialized to 0 when you declare a structure on the stack, padding value is undefined; and gcc typically leave padding with stack dirty content.]

<comment><USER3> Interestingly, the idea of hashing over the bytes of a data structure would be possible in C++, but it is non-idiomatic and instead one would use hash functions for each type and in the case of a struct the individual members would be accessed to build the hash value.

The idea of using bytes is error-prone, but now that you mentioned it, pretty typical of the C mindset.

Of course C++ also has some of these cultural biases. I think they're an important reason why unsafe code continues to be written.

<comment><USER4> I object to reinterpreting bytes of one object as object of another type being C mindset. Yes, this is done sometimes if you really need it (compression being one example) but it's not really something you write everyday in C and doing it to calculate hash is just lazy.

<comment><USER5> Except that hashing a block of memory is likely to be _much_ faster than hashing individual fields once there are more than a couple fields.

IMO the right solution would be a special annotation on a struct that says "I want the logical value of this struct to uniquely determine the bytes of the struct's in-memory representation."

Of course, adding such an attribute without nasty edge cases may be tricky.

<comment><USER6> But this mostly matter for arrays and then an alternative optimization might be to store it as a structure of arrays. This doesn't need the padding and is more simd friendly.

</comment></comment></comment></comment></comment><comment><USER7> The proposal here is way too vague. And if you flesh it out, things start to fall apart: If nul-termination of strings is gone, does that mean that the fat pointers need to be three words long, so they have a "capacity" as well as a "current length"? If not, how do you manage to get string variable on the stack if its length might change? Or in a struct? How does concatenation work such that you can avoid horrible performance (think Java's String vs. StringBuffer)? On the other hand, if the fat pointers have a length and capacity, how do I get a fat pointer to a substring that's in the middle of a given string?

Similar questions apply to general arrays, as well. Also: Am I able to take the address of an element of an array? Will that be a fat pointer too? How about a pointer to a sequence of elements? Can I do arithmetic on these pointers? If not, am I forced to pass around fat array pointers as well as index values when I want to call functions to operate on pieces of the array? How would you write Quicksort? Heapsort? And this doesn't even start to address questions like "how can I write an arena-allocation scheme when I need one"?

In short, the reason that this sort of thing hasn't appeared in C is not because nobody has thought about it, nor because the C folks are too hide- bound to accept a good idea, but rather because it's not clear that there's a real, workable, limited, concise, solution that doesn't warp the language far off into Java/C#-land. It would be great if there were, but this isn't it.

<comment><USER8> I happened to know the idea does work, and has been working in D for 18 years now.

> If nul-termination of strings is gone, does that mean that the fat pointers > need to be three words long, so they have a "capacity" as well as a "current > length"?

No. You'll still have the same issues with how memory is allocated and resized. But, once the memory is allocated, you have a safe and reliable way to access the memory without buffer overflows.

> If not, how do you manage to get string variable on the stack if its length > might change? Or in a struct? How does concatenation work such that you can > avoid horrible performance (think Java's String vs. StringBuffer)?

As I mentioned, it does not address allocating memory. However, it does offer one performance advantage in not having to call strlen to determine the size of the data.

> On the other hand, if the fat pointers have a length and capacity, how do I > get a fat pointer to a substring that's in the middle of a given string?

In D, we call those slices. They look like this:

        T[] array = ...
        T[] slice = array[lower .. upper];

The compiler can insert checks that the slice[] lies within the bounds of array[].

> Am I able to take the address of an element of an array?

Yes: `T* p = &array[3];`

> Will that be a fat pointer too?

No, it'll be regular pointer. To get a fat pointer, i.e. a slice:

        slice = array[lower .. upper];

> How about a pointer to a sequence of elements?

Not sure what you mean. You can get a pointer or a slice of a dynamic array.

> Can I do arithmetic on these pointers?

Yes, via the slice method outlined above.

> If not, am I forced to pass around fat array pointers as well as index > values when I want to call functions to operate on pieces of the array?

No, just the slice.

> How would you write Quicksort? Heapsort?

Show me your pointer version and I'll show you an array version.

> And this doesn't even start to address questions like "how can I write an > arena-allocation scheme when I need one"?

The arena will likely be an array, right? Then return slices of it.

<comment><USER7> How exactly then would one declare a stack variable that is a string that is initialized to "abc", and then later has "1234" concatenated to it, so it's now "abc1234", without using the heap in any way? If the answer is "you can't do that", then that's fine for Java/C#/D, but not for C.

<comment><USER9> You can't do that in C either. Without either: 1) "abc" string happens to be the last variable on the stack, good luck with that. Or 2) You pre-allocate the string to fit a bit extra, not exactly a "solution".

Maybe option 1 is feasible but not really practical, i can only see it being used in _extremely_ low level stuff with a non standard compiler and going through tons of hoops like pre-creating loop-variables used later in the function and disabling optimizer.

<comment><USER7> char foo[9]; strcpy(foo,"abc"); strcat(foo,"1234");

And yes, that's specifically written to be awful and unsafe, but there are circumstances where you need to be close to the metal and carefully resort to more complicated variations of such things. That's what C is fairly uniquely appropriate for.

<comment><USER8> Your example uses three strlen's. It also is at high risk for buffer overflows. Whenever I review code like this, sure as shootin', there's an error in it in the lengths somewhere. Here's the same code using dynamic arrays:

        char foo[9]; foo[] = "abc"; foo[3..3+5] = "1234";

No unchecked buffer overflows, and no calls to strlen. The +5 puts the terminating 0 on.

<comment><USER7> You seem to be confused about the implementation of C's standard string library. There are certainly not 3 strlen calls underneath a strcpy() plus a strcat() call.

But what's the mention of "terminating 0"? The article says that terminating zeros should not be needed under its proposal; and that's what I was saying didn't make sense. [Added:] So, if you didn't just happen to know that the global string variable foo contains a string that was 3 characters long, how would you concatenate "1234" to it? I don't see any way without either double- fat pointers, or terminating NUL.

<comment><USER8> strcpy(s1,s2) does a strlen on s2.

strcat(s1,s2) does a strlen on s1 and s2.

Now, two of the strlen's can be replaced with byte-by-byte copies checking for 0 for each, but that tends to lose the efficiency that a memcpy would bring, so you're pretty much suffering from it anyway.

BTW, here's the strcat I wrote eons ago:

[https://github.com/DigitalMars/dmc/blob/master/src/CORE32/ST...](https://github.com/DigitalMars/dmc/blob/master/src/CORE32/STRCAT.ASM)

It does do two strlen's (the repne scasb instructions). With the improvements in CPUs since there are probably better ways to write it, but that was pretty good for its day.

Here's strcpy:

[https://github.com/DigitalMars/dmc/blob/master/src/CORE32/ST...](https://github.com/DigitalMars/dmc/blob/master/src/CORE32/STRFUNC.C#L194)

which does the test-every-byte method. I think Steve Russell wrote it, but I'm not sure.

If there's anything efficiently implemented in a C compiler, it's memcpy. Being able to implement string processing in terms of memcpy leverages that very nicely. strcat() and strcpy() don't leverage it.

Which do you think is faster (s2 is 1024 bytes long)?

        strcpy(s1, s2);
        memcpy(s1, s2, 1024);

I've dramatically speeded up a lot of my code and other peoples' by replacing the strxxx functions with memcpy. It's low hanging fruit and one of the first things I look for.

<comment><USER10> I'm usually one to lean on your knowledge, but looking at glibc's strcpy [0], I don't see a strlen. I do see two macros, CHECK_BOUNDS_LOW and CHECK_BOUNDS_HIGH, which get defined about here [1].

Am I missing something?

[0] [https://github.com/lattera/glibc/blob/master/string/strcpy.c](https://github.com/lattera/glibc/blob/master/string/strcpy.c)

[1] [https://github.com/lattera/glibc/blob/master/sysdeps/generic...](https://github.com/lattera/glibc/blob/master/sysdeps/generic/bp- checks.h#L28)

<comment><USER8> Good question. I preface this by the fact that I am not any expert on gcc compiler internals, I am assuming how I'd do it.

1\. This implementation tests every byte, as discussed in other posts here. That makes it slow.

2\. This implementation is likely not used - the gcc compiler probably has an internal code sequence it emits for a strcpy.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Yes, that's C's biggest mistake. (But remember, they had to cram the compiler into a 16-bit machine.) No, "fat pointers" are not a backwards-compatible solution. They've been tried. They were a feature of GCC at one time, used by almost nobody.

I once had a proposal on this. See [1]. Enough people looked it over to find errors; this is version 3. The consensus is that it would work technically but not politically.

The basic idea is that the programmer knows how big the array is; they just don't have a way to tell the compiler what expression defines the length of the array. Instead of

        int read(int fd, char buf[], size_t n);

you write

        int read(int n; int fd, char (&buf)[n], size_t n);

It generates the _same calling sequence._ Arrays are still passed as plain pointers. But the compiler now knows how big "buf" is, both on the caller and callee side, and can check.

I also proposed adding slice syntax to C, so, when you want to talk about part of an array, you do it as a slice, not via pointer arithmetic.

The key idea here is that you can call old code from new ("strict") code, and strict code from old code. When you get to all strict code, subscript errors should be all checkable.

[1] [http://www.animats.com/papers/languages/safearraysforc43.pdf](http://www.animats.com/papers/languages/safearraysforc43.pdf)

<comment><USER12> > I also proposed adding slice syntax to C, so, when you want to talk about > part of an array, you do it as a slice, not via pointer arithmetic.

I highly disagree with this. One of the advantages of conflating pointers with arrays is an obvious and very consistent way of indexing and slicing on the entire language that has minimal syntactic baggage.

<comment><USER13> Yes, because typing ptr =&array[0] vs ptr = array is so hard.

</comment></comment></comment><comment><USER14> I absolutely agree. Adding an array type to C that knows its own length would solve so many headaches, fix so many bugs, and prevent so many security vulnerabilities it's not even funny. Null terminated strings? Gone! Checked array indexing? Now possible! More efficient free that gets passed the array length? Now we could do it! The possibilities are incredible. Sadly, C is so obstinately stuck in its old ways that adding such a radical change will likely never happen. But one can dream ...

<comment><USER15> I'll add to this that C having committed to this mistake is one of thr main reasons some people (scientific programmers) are still using Fortran. Arrays with dimensions, especially multidimensional ones, allow for a lot of syntactic sugar that are very useful, such as slicing.

<comment><USER16> Modern Fortran (90 to 2008) has evolved a lot regarding array arithmetic and broadcasting, yet still maintain backward compatibility. I don't think that couldn't be done in C, but as many has pointed out, the problem seems to be why bother when there are already C++/D/Java/C#/Go/Rust ...

However, I'd recommend people who deal heavily with multidimensional arrays but couldn't sacrifice the low-level C environment for a dynamic language to consider using the ISO_C_BINDING of Fortran 2003. It provides fully C compatible native types, and can be compiled together with C (you get gfortran from GCC anyway).

<comment><USER17> Without knowing Fortran, I'd speculate it's easier to maintain backwards compatibility in a language that doesn't have as direct a mapping to hardware as C. Fortran seems to have more abstractions built in.

<comment><USER16> That's true. It predated C but even then abstracted the user away from the hardware (and still does). I wouldn't suggest any use of Fortran beyond number crunching and array arithmetic.

</comment></comment></comment></comment></comment><comment><USER8> Just for fun, type in this program:

        int fred(int a[10]) {
            return a[11];
        }

It compiles without error with gcc and clang, even with -Wall. The code generated by clang is:

        mov EAX,02Ch[RDI]
        ret

i.e. buffer overflow, even though the array size is given. Compile the equivalent DasBetterC program:

        int fred(ref int[10] a) {
            return a[11];
        }

        fred.d(2): Error: array index 11 is out of bounds a[0 .. 10]

And the 32 bit code generated (when using 9 instead of 11 so it will compile):

        mov     EAX,024h[EAX]
        ret

</comment><comment><USER18> Quite surprised to see this not mentioned. C99 allows you to use the "static" keyword in array function parameters like this:

        void foo(int arr[static 10]);

It cannot check whether a passed pointer will point to enough space, but the compiler can warn you if you pass a fixed-size array of a smaller size.

<comment><USER8> Dynamic arrays are far, far more common than static ones.

<comment><USER18> I beg to differ. In C especially, static arrays are quite common as struct members and as static objects at file scope, because dynamic allocations are a pain to manage and unnecessary when the maximum expected size is reasonably small.

When the size of such arrays is computed at compile-time via macro definitions, that feature is quite handy.

<comment><USER8> > when the maximum expected size

I pretty much never use static arrays because if I do I always without fail get a bug report when some user exceeds it.

</comment></comment></comment></comment><comment><USER8> Apparently someone posted this here because of my remark:[https://www.reddit.com/r/programming/comments/90ov9i/a_respo...](https://www.reddit.com/r/programming/comments/90ov9i/a_response_to_a_comment_on_the_riscv_isadev_list/e2thyts/)

Nice to see it get such a nice response!

</comment><comment><USER19> From my experience Go's array (slice) is a far better solution. It does not only carry the size (number of elements), it also carries the array buffer capacity. To me it's the epitome of what arrays should be.

<comment><USER20> Usually people have to refer to a slice cheat sheet to work with it, perhaps it's not an intuitive concept/api

<comment><USER21> That's because of a lack of named methods to perform common operations. It has nothing to do with the fact that slices are fat pointers.

Also, nobody I know constantly looks at a cheat sheet. The concepts motivating the various slice transformations get ingrained pretty quickly.

</comment></comment></comment><comment><USER22> Gimme a break, making stricter requirements on C arrays may theoretically make some things easier, but we're talking 1% improvement. What makes C hard (and great) is requiring an understanding of not just memory, but memory allocation and deallocation schemes. For many beginners this is hard conceptually, but for everyone, keeping track of allocated and unallocated memory is extremely difficult.

<comment><USER23> Disagree. C was the first language I/we learnt, and it's still my favorite.

It's a bit like the first language you learn. For someone from the Latin family of languages, Mandarin's verbal & written structure might seem hard, but for native Chinese, it's second nature.

<comment><USER22> Mandarin may be your first and favorite, but that doesn't make it easy to learn. Same with C.

</comment></comment></comment><comment><USER24> I haven't written much C, and I don't have a firm opinion on whether or not that particular issue is C's biggest mistake. I do think that just this one change sounds radical enough, as far as the effort it would take to convert existing C code that uses the high-risk pattern, that it seems better to just wholesale convert to a language that already mandates safety like Rust or Java. Particularly when you consider all of the other high-risk patterns in C that these other languages eliminate.

</comment><comment><USER25> This is a very good article that highlights the importance of semantics.

</comment><comment><USER26> Conflating pointers and arrays seem pretty minor and not the cause for many bugs.

The main source of bugs in C to me would be pointer arithmetics.

<comment><USER8> Pointer arithmetic is mainly used to access arrays, and is where the buffer overflows come from. Using actual arrays instead allows the compiler to insert overflow checking code.

</comment></comment><comment><USER27> What's the mistake? You pass a pointer and the number of elements, it's just the C way. At any point in time you have to pay attention. What is the proposal here? Make all arrays structures? Or add some weird un-C syntactic sugar?

<comment><USER28> It's a question of priorities. It depends whether your goal is to maximize productivity and minimize the defect rate, or if your goal is to tell people they need to pay attention.

</comment></comment><comment><USER4> Why is this such a serious issue? I mean it is inconvenient to always pass length along with the pointer but it's not that inconvenient. It's a bit more typing but that's where problems end.

</comment><comment><USER29> Agree that this is a problem (if the programmer is not careful).

But serious question, why even bother with this one fix?

The only reason for the fix is so to make it more difficult to make errors.

Fix arrays, then you would fix null pointer, then you might add objects, templating/generics to support a good collections library, rtti, and before you know it you are creating another one of c++, D, go, java. And we already have those.

C paved the way. Why not let it be the end of it?

<comment><USER8> Because buffer overflows are probably the number 1 security bug in C programs.

<comment><USER30> I was wondering why you were championing this idea and agreeing with the posted link in almost every way. Then I went back to the link and figured it out :)

P.S. thank you for everything you have done with D. I read in another HN thread about Better C, and it convinced me that D is the language I should be investing my time in learning and using.

<comment><USER31> > I read in another HN thread about Better C

A good tool to check out, but which hasn't been promoted much because it's new, is dpp[1]. You can directly reference C header files in your D code. With that, betterC mode becomes a viable option for adding to an existing C project.

[1] [https://github.com/atilaneves/dpp](https://github.com/atilaneves/dpp)

</comment></comment></comment></comment><comment><USER32> Isn't the fact that core types don't have a fixed representation a bigger mistake ? a char can be 16 bits, for example, aso.

<comment><USER33> When can a char be 16 bits? I presume it'd still have a sizeof() of 1 though.

<comment><USER32> Texas Instruments C54x DSPs

It can even be funkier, like 12 bits in a char

[https://stackoverflow.com/questions/2098149/what- platforms-h...](https://stackoverflow.com/questions/2098149/what-platforms- have-something-other-than-8-bit-char)

It's a mess

</comment></comment></comment><comment><USER34> Fat pointers manifested themselves in Pascal as strings and are still being used in modern Delphi.

</comment><comment><USER35> I would love one day that programming should adhere to the discipline as in bridge/car safety. Simple malpractice will go to jail for it then there will be no argumment/discussion about this stupid mistake that can be verified by tool Cheers Pham

</comment><comment><USER36> That's why I hope Red/System and just Red in general takes off [https://static.red-lang.org/red-system-specs.html](https://static.red- lang.org/red-system-specs.html)

</comment><comment><USER37> Fair enough.

Arrays losing dimensionality when passed through functions is a pain every now and then.

</comment><comment><USER38> "C retains the basic philosophy that programmers know what they are doing; it only requires that they state their intentions explicitly."

The real 'mistake', is programmers not stating their intention explicitly.

</comment><comment><USER33> Is it better to pass the length of the array, or a pointer to the last valid address in the array? (or one past that) There's probably an advantage in the two types being the same.

Thought of this as I was reading the article.

<comment><USER39> The length is better, since that's almost always what you want.

> There's probably an advantage in the two types being the same.

Not really.

</comment></comment><comment><USER40> The mentioned Safe C Library is now at [https://github.com/rurban/safeclib](https://github.com/rurban/safeclib)

<comment><USER13> The problem with secure C11 Annex K functions, is that they are only secure in name.

They are still as insecure as any traditional C string and memory function.

Yes, they sorted out the issues about then a string always gets its null terminator.

However given that buffer and size are still two different parameters, the issue of mixing up the values is still present.

<comment><USER40> Nope. The buffer size is checked at compile-time. Much like glibc fortify, just better. There's no chance to mix them up. Even the spec'd unsafeties of the truncating n versions are fixed.

<comment><USER13> Can you please explain how strcpy_s() validates that _dest_ actually points to a memory region with enough space for _destsz_ bytes?

[https://en.cppreference.com/w/c/string/byte/strcpy](https://en.cppreference.com/w/c/string/byte/strcpy)

</comment></comment></comment></comment><comment><USER41> Fat Pointers - Pascal has had them since I think the beginning?

So...30+ years later, we decide Pascal was right. Just saying. Shoutout to FreePascal/Lazarus!

<comment><USER8> In Pascal, every array with a different dimension was a different type.

<comment><USER42> That was true in the past, but Pascal has had dynamic arrays for over twenty years. The current versions of Free Pascal and Delphi are nice to use.

<comment><USER8> I kinda gave up on Pascal 35 years ago when I picked up a copy of K+R :-)

The only thing I really liked from Pascal were the nested functions, which I put in D.

</comment></comment></comment></comment><comment><USER43> I feel like Sibiu should just write a new language that is C with fixes, and no more.

<comment><USER13> Has been tried a couple of times, the problem is mostly human not technical.

</comment></comment><comment><USER44> I don't understand what the hoopla is about: in assembler we deal with arrays by having to know the size of each field without giving it a second thought. The solution is to learn assembler first, then move on to C. And AWK, as the next generation C doesn't have this problem, or any of the C problems.

<comment><USER8> I've written a lot of assembler code (including Empire in 100% assembler [https://github.com/DigitalMars/Empire-for- PDP-11](https://github.com/DigitalMars/Empire-for-PDP-11))

Assembler programs are very tedious to write, and so they tend to be rather small. You don't get any help from the non-existent compiler for even simple HLL features like static type checking.

<comment><USER44> As a demo scene coder, I have to disagree vehemently: assembler is a joy to write, at least on MC68000 and 6502 (Amiga and C=64). The only reason why I don't write code in assembler but in C on UNIX is becuase of portability. To me, C is nothing more than a portable assembler with the extra unnecessary code because of the inefficiencies of optimizing compilers.

</comment></comment></comment><comment><USER45> Difference between Array and Linked List is enough to start confusion on pointers

<comment><USER39> Say wut?

</comment></comment><comment><USER46> My guess is this won't be a popular post given the average age of HN participants.

There's nothing whatsoever wrong with C. The problem are programmers who grew up completely and utterly disconnected from the machine.

I am from that generation that actually did useful things with machine language. I said "machine language" not "assembler". Yes, I am one of those guys who actually programmed IMSAI era machines using toggle switches. Thankfully not for long.

There is no such thing as an "array". That's a human construct. All you have is some registers and a pile of memory with addresses to go store and retrieve things from it. That's it. That is the entire reality of computing.

And so, you can choose to be a knowledgeable software developer and be keenly aware of what the words you type on your screen actually do or you can live in ignorance of this and perennially think things are broken.

In C you are responsible for understanding that you are not typing magical words that solve all your problems. You are in charge. An array, as such, is just the address of the starting point of some bunch of numbers you are storing in a chunk of memory. Done. Period.

Past that, one can choose to understand and work with this or saddle a language with all kinds of additional code that removes the programmer from the responsibility of knowing what's going on at the expense of having to execute TONS of UNNECESSARY code every single time one wants to do anything at all. An array ceases to be a chunk-o-data and becomes that plus a bunch of other stuff in memory which, in turn, relies on a pile of code that wraps it into something that a programmer can use without much thought given.

This is how, for example, coding something like a Genetic Algorithm in Objective-C can be hundreds of times slower than re-coding it in C (or C++), where you actually have to mind what you are doing.

To me that's just laziness. Or lack of education. Or both. I have never, ever, had any issues with magical things happening in C because, well, I understand what it is and what it is not. Sure, yeah, I program and have programmed in dozens of languages far more advanced than C, from C++ to APL, LISP, Python, Objective-C and others. And I have found that C --or the language-- is never the problem, it's the programmer that's the problem.

I wonder how much energy the world wastes because of the overhead of "advanced" languages? There's a real cost to this in time, energy and resources.

This reminds me of something completely unrelated to programming. On a visit to windmills in The Netherlands we noted that there were no safety barriers to the spinning gears within the windmill. In the US you would likely have lexan shields protecting people and kids from sticking their hands into a gear. In other parts of the world people are expected to be intelligent and responsible enough to understand the danger, not do stupid things and teach their children the same. Only one of those is a formula for breeding people who will not do dumb things.

Stop trying to fix it. There's nothing wrong with it. Fix the software developer.

<comment><USER47> > _There is no such thing as an "array". That's a human construct._

Oh yeah; social construct, I would say, like gender.

> _I am from that generation that actually did useful things with machine > language._

Unfortunately, most of them are undefined behavior in C.

> _You are in charge._

Less so than you may imagine. You're in charge as long as you follow the ISO C standard to the letter, and deviate from it only in ways granted by the compiler documentation (or else, careful object code inspection and testing).

<comment><USER46> This is a typical misinterpretation of the reality of programming. There is no such thing as undefined behavior. Once you get down to bits and bytes in memory and instructions the processor does EXACTLY what it is designed to do and told to do by the programmer.

Despite what many might believe the universe didn't come to a halt when all we had was C and other "primitive" languages. The world ran and runs on massive amounts of code written in C. And any issues were due to programmers, not the language.

In the end it all reduces down to data and code in memory. It doesn't matter what language it is created with. Languages that are closer to the metal require the programmer to be highly skilled and also carefully plan and understand the code down to the machine level.

Higher level languages --say, APL, which I used professionally for about ten years-- disconnect you from all of that. They pad the heck out of data structures and use costly (time and space) code to access these data structures.

Object oriented languages add yet another layer of code on top of it all.

In the end a programmer can do absolutely everything done with advanced OO languages in assembler, or more conveniently, C. The cost is in the initial planning and the fact that a much more knowledgeable and skilled programmer is required in order to get close to the machine.

As an example, someone who thinks of the machine as something that can evaluate list comprehensions in Python and use OO to access data elements has no clue whatsoever about what and how might be happening at the memory level with their creations. Hence code bloat and slow code.

I am not, even for a second, proposing that the world must switch to pure C. There is justification for being lazy and using languages that operate at a much higher level of abstraction. Like I said above, I used APL for about ten years and it was fantastic.

My point is that blaming C for a lack of understanding or awareness of what happens at low levels isn't very honest at all. The processor does exactly what you, the programmer, tell it do to. Save failures (whether by design or such things as radiation triggered) I don't know of any processor that creatively misinterprets or modifies instructions loaded from memory, instructions put there by a programmer through one method or another.

Stop blaming languages and become better software developers.

<comment><USER47> > _This is a typical misinterpretation of the reality of programming. There is > no such thing as undefined behavior. Once you get down to bits and bytes in > memory and instructions the processor does EXACTLY what it is designed to do > and told to do by the programmer._

Sure.

Only problem is, all you have to do is change some code generation option on the compiler command line and millions of lines of code now produce different instructions. Or, keep those options the same, but use a different version of that compiler: same thing.

> _The processor does exactly what you, the programmer, tell it do to._

Well, yes; and when you're doing that through C, you're telling the processor what to do via sort of autistic middleman.

C is not the low level; you can understand your processor on a very detailed level and that expertise won't mean a thing if you don't understand the ways in which you can be screwed by the C language that have nothing to do with that processor.

I suspect that you don't know some important things about C if you think it's just a straightforward way to instruct the processor at the low level.

> _Languages that are closer to the metal require the programmer to be highly > skilled and also carefully plan and understand the code down to the machine > level._

C isn't one of these languages. (At least not any more!) It's considerably far from the metal, and requires a somewhat different set of skills than what the assembly language coder brings to the table, yet without entirely rendering useless what that coder _does_ bring to the table.

<comment><USER46> > all you have to do is change some code generation option on the compiler > command line and millions of lines of code now produce different > instructions.

It is the responsibility of a capable software engineer to KNOW these things and NOT break code in this manner.

You are trying to blame compilers and languages for the failure of modern software engineers to truly understand what they are doing and the machine they are doing it on.

If you truly understand the chosen language, the compiler, the machine and take the time to plan, guess what happens? You write excellent code that has few, if any bugs, and everyone walks away happy.

And you sure as heck are not confused or challenged in any way by pointers. I mean, for Picard's sake, they are just memory addresses. I'll never understand why people get wrapped around an axle with the concept.

I wonder, when people program in, say Python, do they take the time to know --and I mean really know-- how various data types are stored, represented and managed in memory? My guess is that 99.999% of Python programmers have no clue. And I might be short by a few zeros.

We've reached a moment in software engineering were people call themselves "software engineers" and yet have no clue what the very technologies they are using might be doing under the hood. And then, when things go wrong, they blame the language, the compiler, the platform and the phase of the moon. They never stop to think that it is their professional duty to KNOW these things and KNOW how to use the tools correctly in the context of the hardware they might be addressing.

I've also been working with programmable logic and FPGA's, well, ever since the stuff was invented. Hardware is far less forgiving than software --and costly. It forces one to be far more aware of, quite literally, what ever single bit is doing and how it is being handled. One has to understand what the funny words one types translate into at the hardware level. You have to think hardware as you type what looks like software. You see flip-flops and shift registers in your statements.

This is very much the way a skilled software developer used to function before people started to pull farther and farther away from the machine. It is undeniable that today's software is bloated and slow. Horribly so. And 100% of that is because we've gotten lazy. Not more productive, lazy.

<comment><USER47> > _It is the responsibility of a capable software engineer_

Nobody is saying that it's a acceptable for an engineer to screw up and then blame it on the tools (compiler, slide rule, calculator, ...).

However, if something goes wrong in your work, it's foolish not to recognize the role of the tools, even though it's not acceptable to blame them as a public position.

As objective observers of a situation gone wrong in engineering, we do have the privilege of assigning blame between people and tools. Tools are the work of people also. The _choice_ of tools is also susceptible to criticism. We have to be able to take an objective look at our own work.

</comment></comment></comment></comment></comment></comment><comment><USER48> (2009)

See also discussion from 9 years ago: [https://news.ycombinator.com/item?id=1014533](https://news.ycombinator.com/item?id=1014533) (47 comments)

</comment><comment><USER49> OpenBSD replaced strcat by strlcat, strcpy by strlcpy 20 years ago, in OpenBSD 2.4.

They are implemented in the C libraries for OpenBSD, FreeBSD, NetBSD, Solaris, OS X, and QNX.

They have _not_ been included in the GNU C library used by Linux.

<comment><USER8> Those functions have a separate length parameter. There is no way to mechanically check that the length argument accurately reflects the length of the string. It's not an effective solution.

<comment><USER49> Not an expert, but shouldn't they have a length parameter, it makes sense?

<comment><USER50> I current C, yes, they should. The whole point is, the length parameter should not be separate from the array. It's even worse than that: the parameter is not an "array", it's a pointer to a _single_ element. This whole thing relies on a convention and human attention; can't work in practice.

<comment><USER38> And yet, it clearly does (work).

When it doesn't (work), it is NOT because of a failure in the language; It is because C has (and always will have) the "basic philosophy that programmers know what they are doing;".

Criticising C, is like criticising assembly. What's the point?

If people want to criticise a programming language, then they should _always_ start with C++, not C.

C++ was designed to allow us to develop bigger and more complex programs, and yet, C++ inherited from C?

How stupid was that! But people are happy to give out various awards and medals to the person who made one of the dumbest decisions ever made, in the whole history of computing!

Leave C alone. It's fine. It's C++ that is the problem.

<comment><USER49> Were OpenBSD people wrong, making strlcat and strlcpy ? Honest question.

<comment><USER38> That is a _library_ issue.

Trying to make C 'foolproof' however, is an excercise in futility, and in any case, can only come about by morphing it into a fundamentally different language.

An argument in this thread, is that you shouldn't be able to pass an array without the argument being passed having some _implicit_ 'size' element associated with it. That is NOT C.

Conflating pointers with arrays, that _is_ C.

Again I feel the need to quote this:

"C retains the basic philosophy that programmers know what they are doing; it only requires that they state their intentions explicitly."

If you don't know what you're doing, don't use C.

C should be considered a 'specialist' language - much like doing brain surgery - if you're doing it, you better know what you're doing, else go be a GP or something.

And, if you're project doesn't absolutely require that you use C, don't use it. Instead, use something that is more 'foolproof'. (and I don't mean C++!!!)

D should focus less on being a better C, and more on being a replacement for C++. Then, I might take D more seriously.

No attempt to morph C (i.e. the language, not the library) into something else will ever succeed.

Leave C alone!

</comment></comment></comment></comment></comment></comment></comment><comment><USER51> Should have a 2009 in the title.

</comment><comment><USER52> Why does the author of D want to "fix" C by changing it into D? Concentrate on that D language.

<comment><USER8> I like to fix things. Why not share a simple and effective fix?

<comment><USER52> Isn't there a standards organization / body for C language. Have you proposed this there? What was the outcome?

</comment></comment></comment><comment><USER53> > Notable among these are C++, the D programming language, and most recently, > Go

I would remove go from that list, and add rust and zig.

<comment><USER54> This was written in 2009, didn't rust first appeared in 2010?

<comment><USER55> Why was it posted now without a year in square brackets? That was misleading.

<comment><USER39> The year is in parentheses in the title, and of course it's in the article. I for one have learned to always look at the date something was written. It irks me that there are so many web pages with time-relevant content that contain no date.

</comment></comment></comment></comment><comment><USER56> Meh. What do you do with the dynamically allocated arrays then? Do you pass their dimensions alongside pointer? If that bothers you so much, you can create a struct that holds the pointer and metadata, and do the checks yourself. Calling this "C's biggest mistake" is a bit sensationalistic.

EDIT: besides, you should start new projects in Rust anyway, because it takes security to whole other level. C did a great job, but it's a bit old. :)

<comment><USER57> >besides, you should start new projects in Rust anyway

Thanks, I almost forgot what website I was on for a second.

<comment><USER56> No problem - happened to me 6 hours ago too. </s></comment></comment></comment>


Show HN: My first attempt at a Landing/Sales Page - <AUTHOR> http://www.wppublicist.com Looking to HN for ideas on how it could be improved.  Any feedback would be appreciated. Thanks! <comment><USER2> Not too bad for the first shot. The audience division is standard (bloggers vs moderators). The main section needs a bit more to be the main focal point. Right now it looks as if the main focus is missing due to the amount of negative space in that main section. Also, the logo is in the mud and needs to be pushed a bit more.

But all in all, it is contemporary, consistent, and clear.

<comment><AUTHOR> Thanks for checking it out. I get what you're saying about negative space. I'll look into adding a bit more there.</comment></comment>


GM's self-driving division Cruise raises another $1.15B - <AUTHOR> https://www.theverge.com/2019/5/7/18535194/gm-cruise-self-driving-car-investment-valuation <comment><USER2> Looking at the picture of the test vehicle in that article, I can't imagine what that sensor suite costs. It looks like it costs more than the car itself.

Cruise acquired Strobe last year, a maker of lidar chips, and claimed the acquisition would help them "reduce sensor costs by up to 99%." There would have to be a lot of zeros in the current price for that to be anywhere close to achievable.

> _GM bought Cruise in 2016 for $1 billion to jump-start its self-driving > efforts. The company has said it plans to deploy its fully driverless cars, > without steering wheel or pedals, for commercial ride-hailing use as early > as 2019._

Cruise just raised at a post-money valuation of $19 billion and wants to ship cars without steering wheel or pedals for commercial ride-hailing _this year_.

Elon & TSLA is looking smarter, and saner, by the minute.

</comment><comment><USER3> I wish them luck! I have friends at Cruise but judging from how their cars drive around my neighborhood I'm a bit worried. I know city driving is super tough but these cars are sooo timid. Perhaps it's a safety thing.

Another red flag was a recruiting email I got recently comparing them to all the other self driving car efforts but _not_ addressing anything Tesla is doing. I'm worried they are going to get absolutely destroyed.

<comment><USER4> Why would anyone take Tesla seriously? Anyone that follows the field know they are far far behind the big ones doing this for years (Waymo, Cruise, Zoox,...).

They did a huge PR//Marketing push, but didn't show anything yet.

<comment><USER3> Only Tesla has a reasonable goto market strategy. It's incremental with fast feedback loops and I don't think folks understand what an advantage that is so Tesla is being underestimated.

<comment><USER4> What advantage exactly? Yes they can get some data from some cars sometimes. They definitely don't have the infrastructure to manage the terrabytes per hour that the other classical players generate.

They might have an advantage in 15 years, when you don't need a lidar because cameras will be good enough</comment></comment></comment></comment>


Show HN: My dad designed and built a ventilator prototype with a bicycle pump - <AUTHOR> https://www.dropbox.com/s/d3sq2oq2u4rnxen/77503df8-c6dd-4d44-9fb7-bfa9e4c2255a.mp4?dl=0 <comment><USER2> I've been seeing a lot of ventilator engineers popping up everywhere! It's great seeing such brilliant ideas come to life! However, building a mechanical ventilator is just 1 part of the overall system. The hard part comes in when you have to account for things like injecting precise doses of Oxygen (which vary by the patient) all while controlling humidity (which also varies by the patient). Another challenge to ventilator systems is adding Monitoring/Alarms/Dynamic-Adjustments so you don't have to babysit such a complex feedback loop between it and the patient. Nurses generally have to monitor more than 1 patient at any given point in time. This is where these additional necessities come into play so that they can allocate their care time appropriately. Feel free to add your thoughts.

<comment><USER3> The big thing I can think of is assisting the patient with breathing when needed, yet allowing the patient to still breathe naturally when they can. Things like not forcing air in when the patient is trying to exhale, or removing air when the patient is manually drawing in a breath..

</comment></comment><comment><USER4> Please please, read this before trying to make a ventilator: [https://hackaday.com/2020/03/25/ventilators-101-what-they- do...](https://hackaday.com/2020/03/25/ventilators-101-what-they-do-and-how- they-work/)

<comment><USER5> Great article for non-professionals. Starts with how lungs work and what in lungs needs to be taken into account for a ventilator design. Adds such things as maintaining temperature and humidity - while fighting bacteria which like such an environment. You either spend quite some time working around ventilators (the name is rather misleading - it's a complex device) or you'll learn a few important things when reading this.

</comment></comment><comment><AUTHOR> I'll see if I can list the specs.

<comment><USER6> Yes. Please do.</comment></comment>


Faster Math Functions [pdf] - <AUTHOR> http://www.research.scea.com/gdc2003/fast-math-functions_p1.pdf

<comment><USER2> Part Two at: [http://www.research.scea.com/gdc2003/fast-math- functions_p2....](http://www.research.scea.com/gdc2003/fast-math- functions_p2.pdf)

</comment><comment><USER3> I love the "Basically, WTF?" bullet point.</comment>