copsarebastards

I'd agree with you in some languages, but in C this would be prohibitively difficult. In general, good fluent design uses immutable objects, which makes it basically just a syntactic sugar for functional programming. While fluent syntax is nice, the functional semantics are the real value, and are much easier to do in C (although, as soon as you add in memory management, functional programming often becomes prohibitively difficult too).

That’s the danger of Occam’s razor and of simple answers. “Simplicity” is often a hiding place for our biases. We reach the conclusion we want to reach and then call it simple. --Plaza Garabaldi

I'm not saying you're wrong, I'm saying that I don't actually agree with you that brains being hardwired with information is that hard to explain.

That's actually a very good example, but I'd argue that this is actually a violation of the standard: memset is defined as setting the value in memory. Most optimizations on undefined behavior don't really fall into this category.

I guess you could group this kind of thing into the category of "dead code elimination" which is useful, but results in parts of the code written not producing the specified executable. I have to think on this example more.

Good luck with that. I suspect the only good C is not C.

There's a flipside to this: middle-aged-to-old people aren't choosing to participate in the silicon valley startup culture. As superuser2 noted, a 22-year-old can subsist on ramen while living in a car, while a 45-year-old can't ask his wife and children to do that. But it runs deeper than that: just because a 22-year-old can subsist on ramen while living in a car doesn't mean it's a rational choice.

Most startups these days are producing glorified ad servers that don't actually solve any problems or provide any value. The tech bubble is such that anyone with a young face, a Macbook Pro, and a dumb idea can get funded, but that won't last. As such, working 60 hour weeks for stock that will be worthless in a decade is a bad idea for anyone, regardless of age. Software devs in their 40s have the self-respect and experience that they won't take that kind of deal.

There are some startups which have reasonable business models, but I suspect that time will show that part of those reasonable business models is recognizing the value of experience. In the long run 45-year-old programmer with 25 years of experience working 40 hours a week is easily worth two 22-year-old programmers with 2 years of experience working 60 hours a week. There are certainly young prodigies and ideas which hit the zeitgeist so well that the execution of the idea barely matters, but these are outliers, not the norm.

I'm not missing that; you're making an assumption.

> Computers don't have spirits

But standards committee do.

Agreed. Which is why you should choose a language which was standardized by a standards committee whose goals better align with your goals.

I doubt rust could be ported to a 8bit PIC microcontroller, or to a 6502 keeping reasonable performance characteristics or letting the programmer take advantage of the platform quirks.

I don't think that's true; I think that the current state of Rust tools is such that this is true now, but it's nothing inherent to the design of the language, and I think you'll be able to do quite a bit with Rust in the situations you describe when the tools around Rust are more mature. I can't really speak to this more because I'm not sure why you think this can't be done.

More specifically, they're competing to produce the fastest code for software that follows the C specification to the letter. That's not necessarily the same as producing the fastest code that actually achieves the intended goal.

That's true, but "producing the fasted code that actually achieves the intended goal" is not a problem which can be solved by a compiler--the compiler can't read your mind.

Attempting to represent a reasonable approximation of reading your mind is the responsibility of the specification. You can definitely do better than C, but I doubt you could have done better 4 decades ago when C was designed.

What GCC is doing subverts the purpose of writing in C, which is to get close to the machine and instruct its processor to do certain things.

That's not the purpose of writing in C. It's a goal you might be able to achieve with C, but I'm not sure why that's your goal, and it's certainly not the goal of everyone who writes C. I think more people who write C do so with the coal of producing programs that run fast or with a minimal memory fingerprint.

This is a case of following the letter of the law (in this case the C standard) while disregarding its spirit: all the undefined behaviour was so that C compilers could accomodate for odd architectures while remaining close to the metal, not so that compiler programmers could go out of their way to turn their compiler into a mine field.

Computers don't have spirits; they work as you tell them to work, to the letter, and if you're remaining close to the metal, your language will indicate that fact. Optimizing undefined behaviors doesn't make C a minefield; low-level programming for different architectures just is inherently a minefield. C was a minefield before these optimizations were added.

Rust is extremely impressive because they've found so many ways to do high-level programming while maintaining low-level performance. But they can only do that because they have the benefit of the 4 decades of programming language research that have occurred since the basics of C were designed.

Yeah, I'd go so far as to argue that if you need security, you probably shouldn't be writing C.

I don't think people's inability to distinguish between paying for software and paying for programming makes the statement "Software should be free" a bad statement.

I understand the problem, I'm saying that it's not GCC's problem. If you don't want undefined behavior, don't put undefined behavior in your code. The code you wrote isn't clear or reasonable, because it relies undefined behavior. It's a valid criticism that this code does appear to be straightforward when it isn't, but that's not a criticism of GCC, it's a criticism of ANSI C. If you don't like it, use a better language. C was designed 4 decades ago; and they can't possibly have forseen every problem that we've discovered in that time.

Writing code that depends on the value of unread memory is bad for security.

I think a better design would be to separate mutators from pure functions. If a procedure mutates state, it should have a void return type, and if a procedure returns a value it should be a pure function that doesn't mutate state.

This is, of course, a rule of thumb, not a hard law. Some exceptions:

1. I think it's okay (and in fact, idiomatic in C) to mutate state and return some sort of information about what occurred (i.e. a success flag, a number of characters written, etc.).

2. Isolated mutations such as logging sometimes make sense in an otherwise pure function.

That complaint isn't a valid complaint. If the checks relied on undefined behavior, the code wasn't secure. If you want to rely on the behavior of a specific version of a specific compiler, then you need to define that in your dependencies instead of pretending that you've written general-purpose C code. This isn't even just a GCC problem; compiling the code on a different compiler breaks this too.

On the first point I think we are talking about two different things. I am not talking about the entire signup list of Old Reader, I am talking about a user of Old Reader that uses Google OAuth to access Old Reader. In this case Google already has this particular user data.

We're talking about different things because you missed my point a few posts ago when I said that the problem it solves is "how do we (a big company) get smaller companies to outsource as much of their user data as possible to us". User lists are data.

Some provide it to make it easier for their users to login

If that's their goal, they're failing to achieve it. OAuth requires more steps than a simple username/password signup form, including going to a completely different site to give permission to log in with your data. Google/Facebook/etc. and other OAuth providers aren't stupid: they know that's not a good solution to that problem. If they really wanted to solve that problem they'd write a login library (something like Reddit's signup/login system) which would solve that problem better. The reason OAuth isn't implemented that way is that the goal of OAuth is not to make it easier to sign up and log in.

Most see it as a benefit for their users to only use one login.

There is nothing that stops users from using one login everywhere; OAuth does not aid this in any way. I use the same login on all the sites where I don't care about the security of my account.

You have yet to make any compelling argument that users or sites which use OAuth are gaining any benefit from OAuth. The only people who benefit from OAuth are OAuth providers.

You're right; I'm sorry for misreading your intention. I've edited my post so it's not as directed at you.

I don't think it's the language's fault either: C is four decades old, and being bound by reverse-compatibility, they can't integrate much of the programming language research that has happened in the last four decades. I'm a less concerned with placing fault for the problem than I am with placing the responsibility for fixing the problem, and that's clearly on the writer of the program which uses undefined behavior.

I think choosing Rust might be a reasonable way to avoid the problem in the first place, so I agree with you there, but there are also reasons to choose C over Rust. Personally, I write a lot of C code because I prefer to build on a GPL stack. This is one of the reasons I'd like to see Rust added as a GCC language. Sadly I don't have the time to do it myself.

On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. --Charles Babbage

The modern version of this seems to be:

"Mr. Babbage, I put the wrong figures into the machine and the wrong answers came out! Please fix it this, this has security implications!"

You can't reasonably expect the compiler to make your insecure code secure.

Calling them "language lawyers" is some entitled crap. GCC commits to implement the specification of the language. Expecting them to maintain some huge number of undefined behaviors is literally expecting them to do something they never said they would do and couldn't do even if they said they would.

There's a parable where a man goes to the doctor and says, "Doctor, whenever I drink my coffee with the spoon in the cup, the spoon handle pokes me in the eye and it hurts." And the doctor says, "Well, stop doing that."

If you wrote `foo(bar(), baz())` and `baz()` relies on state mutated by `bar()`, your code is bad, and you should feel bad, because experiencing those bad feelings is the way you learn to not write bad code. This code was wrong before the compiler reordered the calls, it just failed silently for a while. The compiler isn't responsible for fixing your bugs, you are.

People need to stop expecting other people to fix their problems.

The only reasonable thing to say about this was already said upthread of the page, and quoted here:

I have worked on many programs, and whenever I found such a problem (typically called a "portability problem"), where the code was assuming something that the language did not guarantee, I fixed the program rather than bitching about the compiler.

Interesting. Yeah, that makes a lot of sense.

The Swiss style seems to have influenced the covers of a lot of old sci-fi books, so I mentally associate these kinds of color schemes with faded old paper and sitting indoors on a rainy afternoon.

i'm sorry, but conflating the issue of a perceived disparity with 'beliefs' about social gender consensus is unhelpful and only incites issue derailing ire

It's not a conflation, it's acknowledging what I believe to be a causal relation. If I'm correct, changing the beliefs will help fix the issue.

instead i think the argument should be to fund a state run universal shelter program well enough that specific interest shelters get phased out proactively

Yes. The solution to disparity is enough abundance that it doesn't matter.

Analogies aren't evidence, they're a tool for explanation, again by semantic definition.

Agreed, that's what I've been saying all along.

So then why did you use an analogy? Did you really think the sentences "Privacy is easily available" or "People only have to use privacy tools when they are doing something that they want to keep private" needed explanation? Perhaps I assumed you were using it as evidence when you weren't, but you have to admit that's a reasonable assumption given that the analogy is completely pointless otherwise.

It's committing a no-true-scotsman to say that "privacy isn't as easily available as oxygen" when you change it to "true privacy is is really perfect privacy" when faced with HTTPs and OAuth.

Imperfect privacy isn't privacy. Either people are able to look at your data or they aren't. If people are able to look at your data, you don't have privacy. This isn't a complicated idea or a "no true scotsman" fallacy, it's the meaning of the word "privacy".

We have plenty of evidence showing that the NSA surveils data which is "protected" by HTTPS, ergo, HTTPS does not provide privacy. And the NSA isn't the only actor with this capability.

And OAuth doesn't provide privacy. It's not even the problem that OAuth tries to solve. OAuth provides authentication, which is an element of privacy, but it takes more than simply showing that a person is who they claim to be to provide privacy.

All privacy & security tools are are imperfect, but most of us find the right level, rather than live in a faraday cage in our mother's basements (that's the point).

That's exactly not what happens. The average user simply is not informed enough to make an educated choice about what level of privacy they want and make choices to get that level of privacy. As a result, people don't find the right level of privacy. Closeted gay people get outed by their Facebook friend graph, pregnant teenagers have their pregnancies publicized by their targeted ads, celebrities have their nude photos leaked to the public, adultery website users and corporate employees have their information leaked, women are found by their jealous law enforcement exes misusing surveillance technologies. Only a fraction of these people actually knew what risk they were taking when they friended someone on Facebook, searched for goods on Amazon, texted a nude photo to a lover, put their credit card into a website, gave their info to their employers, or made a phone call.

Obviously living in a faraday cage in your mother's basement isn't the answer: that's a straw man argument.

The answer, in my opinion, is both social and technical. Socially, we need to get people to prioritize privacy and use privacy by default, we need people in power to respect and protect the right to privacy rather than actively taking it away from people. From the technical side, we need privacy tools that are faster, more secure, and easier to use, and we need decentralization so that violating people's privacy is no longer an option.

So don't collect any more information than you need.

Choosing OAuth amounts to a very bad assumption that you'll never care about who your users are.

I do not know who is the uneducated here, but in the case of OAuth, the other company already has the user data.

No, they don't. Google, for example, doesn't have the entire signup list of all the users of The Old Reader, but they have a lot of The Old Reader's users, because The Old Reader outsources authorization for some of its users to Google. That's data that Google is collecting via OAuth, and you'd better believe they use that data.

What OAuth enables is to use their information to verify the user.

That's what it enables for the OAuth consumer, but there are far easier ways of doing that. The difficulties of OAuth exist because OAuth doesn't serve the OAuth consumer's needs, it serves the OAuth provider's needs.

At a very basic level, when I was volunteering helping the homeless, I saw a great deal of disparity. There are many homeless shelters and programs that only take in women and children, and many shelters which accept people of all genders but have limited space will make men wait to gain entrance, while letting in women and children, so that if someone doesn't get in, it's always men. Donations are frequently given under the condition that they go to help homeless women and children.

I do understand some of the legitimate reasons for this: women are at higher risk to be raped and experience more medical issues related to homelessness. But this only accounts for some of the disparity.

Part of the issue here is that there's a belief that adult males should be able to support themselves. This is evident in the programs that do serve men: while homeless programs that target women provide food, shelter, medical care, and childcare, the few homeless programs which target men almost universally focus on helping homeless men get jobs. Men do experience privilege in employment when they're actually employed, but this idea is inapplicable to the homeless. Most homeless people are mentally ill, and a mentally ill man is no more employable than a mentally ill woman.

Analogies are inexact by semantic definition, and that doesn't make then "faulty".

Well, it makes them useless as evidence. An argument by analogy simply isn't a valid argument. Don't you remember the "You wouldn't steal a car" ads?

Privacy is readily available through https, two factor OAuth, etc.

HTTPS is broken by privileged man-in-the-middle attacks (attacks where the attacker has key signing power) and downgrade attacks. And that is when it's even available (it isn't always). And even against attackers with less power, it only provides privacy for what you send over the wire, not who you send it to. And finally, this all assumes that you're sending your data to an entity which won't simply sell it to whoever is willing to pay a few bucks (an uneducated user might think, for example, that data sent through GMail is private).

I'm not even gonna touch "two factor OAuth"; I'm not sure what kind of privacy you even think that provides.

In short, you clearly have no knowledge about what does and does not provide privacy. It would behoove you to not make claims on topics you are ignorant of.

I'm not questioning what you're saying, as it seems to be correct based on what I know (I may or may not have watched the Helvetica documentary) but what's with the graininess in the color picker? It doesn't fit with anything else I'm looking at on this topic.