Q: Why can I access an out-of-scope C++ var? A: So you rent a hotel room...

http://stackoverflow.com/questions/6441218/c-local-variable-can-be-accessed-outside-its-scope/6445794#6445794

by sutro • 15 years ago

418 98 15 years ago

Title is a bit misleading... but still a great answer.

briandoll• 15 years ago

Great analogy and well written. We often see attempts at this style of explanation, but we usually fail at one or both of those qualities.

While I wish I saw more of this style of teaching in technical publications, it's admittedly rarely done well enough to convey the point.

solutionyogi2• 15 years ago

Eric Lippert is a prolific writer and is amazing at explaining anything related to computer programming. His blog is a MUST read for every .NET developer: http://blogs.msdn.com/b/ericlippert/

I also follow Eric's activity on SO here:

http://stackoverflow.com/users/88656/eric-lippert?tab=activi...

Some of his answers which I liked:

http://stackoverflow.com/questions/2704652/monad-in-plain-en...

http://stackoverflow.com/questions/921180/how-can-i-ensure-t...

http://stackoverflow.com/questions/5032081/coding-style-assi...

He is on HN as well:

http://news.ycombinator.com/threads?id=ericlippert

jseliger• 15 years ago

Heads up: the two links at the top go to the same source:

Eric Lippert is a prolific writer and is amazing at explaining anything related to computer programming. His blog is a MUST read for every .NET developer: http://blogs.msdn.com/b/ericlippert/

I also follow Eric's activity on SO here:

http://blogs.msdn.com/b/ericlippert/*

Reply

solutionyogi2• 15 years ago

I don't know who downvoted you, you are correct. I fixed up the links.

Reply

yread2• 15 years ago

this one is an eye opener and very humble too http://stackoverflow.com/questions/2186595/c-is-there-a-diff...

edit: also thanks for making me spend probably next several hours reading through all that stuff :)

edit2: oooh this one is good as well http://stackoverflow.com/questions/3110154/why-is-the-explic...

edit3: Not from Eric but check out this C# code:

    sbyte[] foo = new sbyte[] { -1 };
    var x = foo as byte[];    // doesn't compile
    object bar = foo;
    var f = bar as byte[];    // succeeds
    var g = f[0];             // g = 255

edit4: oh and check out this description of c# compiler actions http://stackoverflow.com/questions/1917935/how-does-c-compil...

Reply

rchowe• 15 years ago

Is twos compliment behavior guaranteed in C#?

Reply

wheels• 15 years ago

Local variables in C and C++ are just put on a stack (i.e. the stack) and its behavior is pretty predictable. For example:

  #include <stdio.h>
  
  static int *foo(void)
  {
      int i = 42;
      return &i;
  }
  
  static int *bar(void)
  {
      int i = 43;
      return &i;
  }
  
  int main(void)
  {
      int *f = foo();
      /* with next line commented out prints 42, with it, 43 */
      bar();
      int i = *f;
      printf("%i\n", i);
      return 0;
  }

Until you've made another function call that reuses that space on the stack you'll almost certainly still have valid values when accessing those local variables by address. Things are a bit vaguer in C++ where those variables may be objects which have destructors which have already been called.
Edit: Made it predictable, per caf's (correct) comment by adding:
int i = *f;

Reply

caf• 15 years ago

It's not entirely predictable, because, for example, the compiler may have already stored the first parameter of printf (the address of "%i\n") before it gets around to dereferencing f, and it may have stored it in the same location on the stack that was used for `i` in foo and bar.

It's also possible that foo() got inlined, so that the space used for `i` in foo() ends up being used for `f` in main.

Reply

pvarangot2• 15 years ago

Also compiling with heavy optimization (such as -O3) can blow a variable out of the stack and into a register that can quickly get reused, or can also inline functions. Both of this can break the perceived predictability.

In fact, here on my computer, your code example behaves differently when compiled with gcc default optimizations and when using -O3.

  [peter@laptop ~]$ gcc test.c -o test
  [...] warnings
  [peter@laptop ~]$ ./test
  43
  [peter@laptop ~]$ gcc -O3 test.c -o test
  [...] warnings
  [peter@laptop ~]$ ./test
  42

I'm inclined to believe in this case this is happening due to function inlining, but I haven't checked the assembly.
Edit: My post refers to the last version of your code, with the int i = *f; line in it.

Reply

alain94040• 15 years ago

In embedded systems where interrupts are handled from user space (or the code you show is in the kernel), then it is guaranteed that your stack will be obliterated if an interrupt occurs at the exact right time, so your value will not be there.

This is not academic: I have debugged code that relied on that behavior, and would fail once in a million runs. Very frustrating to figure out.

Reply

bodyfour• 15 years ago

Same in userland if you're using POSIX signals (and you haven't explicitly configured a separate sigstack)

All it takes is the user resizing their xterm and JUST the right moment and the SIGWINCH handler will happily step on your out-of-scope stack objects.

Reply

dkersten3• 15 years ago

Very true.

Of course, the exact details depend on the architecture. For example, I've been doing a bunch of PIC24 microcontroller programming recently, in both C and assembly. On these, an interrupt will store the return address on the stack, obliterating the variable. However, if more dead variables are on the stack, they may be left intact, since PIC24 uses shadow-registers to stash away the users register values temporarily so that the interrupt may reuse them. That is, they are not temporarily pushed onto the stack (obliterating more dead variables), but rather stashed in shadow registers.

Actually, interrupts store two 16bit values from the stack - a 24bit instruction pointer and the lower 8bit of the STATUS register, so would destroy 32 bits worth of dead variables' values.

Reply

sausagefeet• 15 years ago

Standarians will point out that what you've said is implementation dependent, for the standard makes no claims as to what you are talking about other than defining the lifetime of objects. Your edit does not make it predictable beyond the specific implementation you tested it on.

Reply

nuxi• 15 years ago

It's not that predictable - try changing bar() to

  static int *bar(int dummy)

and call it with
bar(10);

Reply

codexon• 15 years ago

I'll probably get downvoted, but I think elaborate real-life analogies like this are more likely to confuse novices than help them.

A better explanation in my opinion is to draw a diagram of a stack and showing that returning from a function just decreases a pointer. C++ programs don't scrub the top of the stack once you finish a function because it is a waste of time.

If another function was called before the 2nd call to foo(), then the variable on the stack would be overwritten.

Reply

pyrtsa• 15 years ago

Yeah, the hotel room analogy breaks as soon as you realize that visiting some completely other hotel room will already overwrite that variable in the first one.

But it was a fun story, though.

Reply

schleyfox• 15 years ago

While that is more accurate and I think that programmers should understand how computers work, as well as C calling conventions, in this case the analogy helps. People who know what the stack is (other than something that can be overflowed) as well as how functions are implemented would likely never think to ask this question. By the time you give the satisfactory "real" answer, you've written the better part of an intro architecture lecture (at my school, I think we probably had 2 or 3 lectures and a lab to get to this point, with other digressions).

The real explanation would also be less complete than the analogy as going into the "construction of a football stadium", etc. would have to consider optimizing compilers, virtual memory, and the other things that could get really mucked up. The analogy is accessible even to people who don't program, rather than to just those who have seen %ebp and %esp.

Reply

wh-uws• 15 years ago

Let me preface this by saying I am not attacking you just stating an opinion about the sentiment

Thats the exact type of thinking that keeps so many people away from programming and computer science.

A nice accessible answer that helps a person make a logical leap in the right direction is so much more important to a novice than pedantry.

Its not a perfect answer but to a person who has no clue whats going its a lot more helpful to get some idea

Reply

olavk• 15 years ago

The analogy is supposed to explain the concept of undefined behavior, not the details of memory management.

If you are used to safe languages, the concept of undefined behavior might be confusing. In those languages, an operation is either allowed or not allowed, and if it is allowed it has well-defined behavior. In C a number of operations does not have well-defined results, but is still technically possible to perform, or might be possible depending on circumstances. But you shouldn't use them. The analogy is supposed to explain that.

Reply

sliverstorm2• 15 years ago

undefined behavior is fun. All this stuff gets a lot more interesting in microcontrollers, where security is not an issue and you sometimes have to manage memory directly and store data between power cycles.

Reply

ma2rten2• 15 years ago

Sorry for the off-topic rant, but is it only me or are people, who start with "I'll probably get downvoted, but ...", never actually downvoted? Maybe it's some kind of reverse psychology, like parents who tell their children the opposite of what they actually want them to do. Or maybe the downvoting behavior on HN is actually better then people think and different options are actually valued.

Reply

jamesaguilar• 15 years ago

I've noticed that when people start their comments with "sorry for X," or "is it only me . . ." they tend to get upvoted. This could be another instance of the same reverse psychology you posit.

Reply

msluyter• 15 years ago

I agree, in particular, that the image of how the stack works is critical for really understanding the problem. The hotel analogy is nice, but doesn't help much in generalizing or extrapolating to other issues.

Reply

scott_s2• 15 years ago

Analogies like this are stepping stones, not the destination. I try to both use an analogy and give the fullest explanation that I think they can handle. The analogy tells them the structure of the complete answer. The complete answer often has concepts that are new to them, and the more unknowns in something, the harder it is to learn. The analogy allows them to understand the structure of the reason, which removes an unknown.

Reply

dools• 15 years ago

I'm not sure I agree entirely with this explanation. He emphasises that this is unsafe behaviour that is protected against in safer languages - I've never heard it said that the use of pointers should be considered unsafe and there are also pointers in other languages that exclude things like multiple-inheritance and have garbage collection (which could be considered safer languages).

I like the room key analogy (almost) but I don't think it needs to be stolen and I don't think all the talk about policies and contracts is necessary at all.

It could simply say the thing you're returning is not the local variable. It is a pointer.

I have a box and instead of giving you the box I give you a key to the box. Anytime you want to use the contents of the box you must come over to the box and open it, but you can't take the box with you. If you want to put something in the box you just walk over and put it in - but here's the rub: you have no guarantees that you're the only one with a key. I could give out the key to a bunch of people so you don't know what will be in the box and who owns it.

Use with caution!

Reply

stoney2• 15 years ago

I think he means that pointers are unsafe in the same way that dynamite is unsafe. They both have legitimate uses, but you need to be very careful when you are using them. (Rather than unsafe in the sense of don't use them at all).

I like your box analogy, but I don't think it goes far enough - with C++ pointers it is not always ok to put something in the box. If the pointer is out of date or invalid there is a chance that writing to it will make the OS kill the entire process.

Languages with garbage collection don't tend to have that kind of problem, since whatever is at the memory location will stay at that location until everyone surrenders their pointers.

Reply

maranas2• 15 years ago

I agree with you for the most part. C/C++ lets you do what you want, presumably because you know what you're doing. But I don't agree that pointers are evil, and should be avoided. If you want to do any practical programming with C/C++ at all, you have to learn how to dynamically allocate memory and use pointers. Generally, pointers work as advertised. It's the cases where they work when they shouldn't that is the problem. In these cases a compiler usually warns you, so you are still covered. So in C/C++, just because it works, doesn't mean your code is right.

Reply

delinka• 15 years ago

"I've never heard it said that the use of pointers should be considered unsafe..."

Please pardon the bluntness, but that sounds like a fundamental failing of whomever you've been learning. Use of pointers in the C family of languages is unsafe. That's "unsafe" in the context of computer languages.

As for the analogy, the talk about policies and contracts is important. There's nothing in the hotel preventing you from using the key to gain unauthorized access to the room just like there's nothing in C++ to prevent you access memory you have no business trying to access.

Reply

stevetjoa• 15 years ago

200 upvotes in nine hours?! Is that a Stack Overflow record?

Reply

leon_2• 15 years ago

no, I guess many people started to understand this behavior just now. (something you don't meet when all you do is javascript and ruby/python)

Reply

DrJokepu• 15 years ago

Maybe I'm an elitist but I find it rather scary that people write code for a living without understanding concepts such as this. It's easy to forget what a huge service StackOverflow provides to the developer community by spreading knowledge in an easily accessible and entertaining fashion.

Reply

mikle• 15 years ago

It's great that you don't meet this since Python/Ruby were designed not to have the same problems C/C++ had.

Reply

yaakov3415• 15 years ago

I say this as a C++ programmer (C++ is essentially the only choice in the domain in which I currently work), but this really underscores how unreasonable C++ is for writing secure/high reliability applications. On the one hand, the compiler will curse you out for trying to use a non-const iterator in a const function (sheesh, what kind of an idiot are you, anyway)? On the other hand, you can read and write to every bit of memory allocated to your application, and it will stand by and do nothing. I think the number of applications which had buffer overflows at least at some point is statistically indistinguishable from 100%.

Try this hotel analogy: you go to a hotel in which you once stayed, and tell them that you're going to dump every bit of possessions and furnishings in all the rooms outside on the street, rifle through them, set them on fire, then photograph all their guests in the nude and distribute the pictures. Most hotels will object. C++ won't.

Reply

ANH2• 15 years ago

FWIW, the Clang compiler does warn about this situation:

  undefined.cpp:4:13: warning: address of stack memory associated with local variable 'a' returned return &a;

Edit: So does gcc.

Reply

yaakov3415• 15 years ago

Not nearly enough.

Note that C++ combines C's vulnerabilities with non-transparency. Suppose you have a data structure like "set of maps of strings to pointers to vectors." That's actually not a complicated structure for a modern application. Now suppose the new guy on the team, who is working on a function which is not taking user input and is not security-sensitive in itself, puts a pointer to a local variable in this structure. Now you, writing a security-sensitive function, write something to this structure. You're overwriting the stack, and NOBODY will warn you or do anything about it. You're certainly not going to get a compiler warning, and I don't think the "new guy" got one either when he did this - he was not directly returning the pointer. This means that you need to treat every line of the application as security-critical. Some people do, but for most, it's not realistic. There are some tools and techniques to help you, but it's not 100%. And it needs to be 100%, since the attacker needs 1 entry point.

Reply

yaakov3415• 15 years ago

It seems from some of the comments down the thread that the idea of writing over memory in C++ is new to many people. Let me introduce another couple of concepts.

You don't have to stop with writing over the variables. You can write over the return address of a function, which is stored on the same stack as the variables. If you write some user-supplied buffer to memory, and you didn't carefully make sure that the memory is allocated for this purpose, the (malicious) user can supply you with data that will set the function's return address to something in his buffer, and the function will go on executing his code. That's called a buffer overflow vulnerability, and it's been well known and exploited for decades; half the patches you see coming down the pipeline used to be for this.

Now, there are good ways to protect against buffer overflow vulnerabilities. If you make the stack and data non-executable, and the pages containing code non-modifiable, then seemingly there is no place for the attacker to place his code and get it to run. Modern processors support this in hardware.

Except that some people came up with something called return-oriented programming. This works by finding little pieces in your code that do something simple like increment a register or write a byte of data, followed by a "return" instruction. These tiny pieces of code are called "gadgets". You can usually find enough gadgets to make a Turing-complete language. Then you write a compiler which transforms your code into a stream of calls to the gadgets. Now all you need is one overwrite of the return address on the stack, and you can start playing the application like a piano, without ever executing data or modifying code. There are now tools to automate all this.

I don't want to reveal anything about where I work, but we write applications which need to be reliable and secure. We have regular meetings to discuss vulnerabilities and security techniques. At the meeting where we discussed return-oriented programming, when we asked what we could do to protect from it, the consensus answer was "You can't. Don't make any buffer overruns." The problem is it's not clear that anyone ever wrote a program free from those.

Since hotel analogies seem to be so popular, here you go: http://en.wikipedia.org/wiki/Psycho_(film)

Reply

yaakov3415• 15 years ago

One last addition - I hope I'm not overstaying my welcome with all these little lectures on security. It used to be that a buffer overrun typically resulted from carelessness, like

   char name[100]; //Who has a name longer than 100 characters?
   printf(“What is your name?”);
   scanf(name, ”%s”);

It turns out that the same kind of people who have names like "Robert'); DROP TABLE Students; --" sometimes have 150-character names with a return address and a few bytes of malicious code. That's something that you handle kind of like you sanitize your inputs. You don't pour user input into a limited space. Scanf is deprecated now, and this kind of a vuln is becoming rare.
But as I explain a couple of comments down, a buffer overflow doesn't have to be this simple. You can get a bad pointer in a structure anywhere in your program, and when you use the structure, you will overwrite the stack. It's very hard to catch that kind of vuln - basically, it's a race with you (and white hats) vs. black hats. This is why I welcome the switch from C/C++ to managed code which is happening now, but very, very slowly.

Reply

pvarangot2• 15 years ago

Your post is indeed very useful, but for the sake of completeness I'll add some remarks to it.

The technique you call Return Oriented Programming is not as new as you seem to beleive. It evolved from ideas and techniques that have been arround since late 90s, mainly what is called "return to lib". Surely it was not as popular and hyped as it is today, but then again neither was a non-executable stack popular back then.

Also an effective implementation of Address Space Layout Randomization serves as a mitigation to ROP shellcode. I'm no expert on exploit writing but I beleive that modern ASLR on 64 bits system will be very difficult to bypass except for the most skilled exploit writers out there, and they would most surely need to pinpoint exact versions of your OS, libraries and layout of your binary.

I don't know any specifics about your work, but though "You can't. Don't make any buffer overruns" is a very good advice, its rather simple-minded... I firmly believe any bug can be leveraged into code execution until someone shows the contrary for said bug, but that doesn't mean that a single technique is the silver bullet of exploit writing. To be able to code in a security-minded way, as one learns about were each protection might fail, one must also learn about how each exploit writing technique might fail.

A good introduction to ROP in the form of a somewhat self oriented self contained blogpost can be found here:http://eticanicomana.blogspot.com/2010/06/so-called-return-o... by a guy from Immunity Inc. I'm mentioning his post because I think one of the automated gadget finding tools you may be talking about is their Immunity Debugger/DEPLib.

Reply

RodgerTheGreat• 15 years ago

I'd heard of Return-Oriented Programming, but it just occurred to me that it's the same idea as 'Threaded Code': http://en.wikipedia.org/wiki/Threaded_code

Reply

yuhong• 15 years ago

On 32-bit Windows, don't forget SEH put exception handlers on the stack too.

Reply

kragen8• 15 years ago

> The problem is it's not clear that anyone ever wrote a program free from [buffer overruns].

There are lots of programs in languages like COBOL that don't have buffer overruns, because they don't have pointer arithmetic.

Nobody has ever found a buffer overrun in qmail, despite looking very hard for many years.

It is very likely that my toy compiler http://canonical.org/~kragen/sw/urscheme/ doesn't have any buffer overruns. It's written in Scheme, generating x86 assembly. The only places that do pointer arithmetic under the control of user code are string-ref and string-set!, which call the same check-array-bounds routine to verify that the index is within the bounds of the string. Unless I fucked up that check, which is seven lines of assembly, there's no way to get a buffer overrun in code compiled with the compiler.

(Technically there's also code having to do with closures that could potentially have a buffer-overrun bug, but it's much less likely. Indeed, virtually any of the assembly language output of the compiler could conceivably have a bug that smashes memory. But it probably doesn't.)

There's also no way to efficiently move data in and out of a string, because every access is individually bounds-checked. But reasonably-efficiently-bounds-checked array access, while it's more than seven lines of assembly, isn't an unboundedly-large problem either. It's just that there's always a tradeoff between safety and efficiency.

Reply

jordanb2• 15 years ago

C++ is perhaps the only language with a strict typing regime that doesn't have any memory safety.

This is ridiculous because safe memory access is more easy to implement, places fewer restrictions on the programmer, and is much more important for writing secure software than strict typing. Unfortunately, it does proscribe pointer manipulation patterns which are popular in C programming, so it was excluded from C++ to align with the "C with classes" marketing.

Reply

yaakov3415• 15 years ago

Right; we're just so used to C/C++ that this seems normal. Here's Eric Lippert telling someone "look, if you check out of a hotel room, your stuff might still be there for a while, right?" Right. Makes sense. (Not blaming Eric Lippert for anything - he didn't design the language, and his explanation is, of course, 100% correct).

What I'd be telling him is this: "You've discovered an EXTREMELY dangerous feature present in C/C++ and almost no other common language. The whole security industry has spent DECADES plugging holes caused by unsafe memory accesses, and it didn't win the battle. The very first internet worm in 1988 used a buffer overrun, and the patch you downloaded yesterday was probably for one of those, too. Of course, unsafe memory access may make a program unreliable, as well as insecure. Be VERY careful."

Of course, I might just need to become more laid-back and mellow...

Reply

scott_s2• 15 years ago

It wasn't marketing. When C++ took off as a language, such memory safety was a luxury. I've read Stroustrup's Design and Evolution of C++, and I don't think strict memory safety was even considered. Saying it was "excluded" implies that it was considered, when I think the kind of programming they wanted to support - systems programming with minimal performance overhead - precluded it from consideration.

Reply

coliveira• 15 years ago

C/C++ doesn't have this restriction because the hardware doesn't have it. In assembly you can do whatever you want with memory. C was created to give as much access as possible to the hardware, while still providing many of the features of high level languages. It is not the language that is betraying you, it is you that is not clear about what the language can do.

Reply

T-hawk• 15 years ago

you go to a hotel in which you once stayed, and tell them that you're going to dump every bit of possessions and furnishings in all the rooms outside on the street, rifle through them, set them on fire, then photograph all their guests in the nude and distribute the pictures. Most hotels will object. C++ won't.

Of course, then when the assigned task is to ransack a hotel (what if you're filming Spinal Tap or conducting a riot response police drill?), the other hotels won't even speak to you and you can't perform the task at all. Hotel C++ does not object so it becomes the resource by default.

Reply

leif6• 15 years ago

C++ compilers will actually warn you about plenty of memory issues if you ask them to, by writing type-safe code and turning on lots of warnings. Static analyzers today are very good, and will catch a surprisingly good amount of unsafe memory problems that even the compilers miss. The rope it gives you is there for people that need it, but if you don't want it lying around because you're afraid you'll hang yourself, you can always ask the compiler to take it away.

Reply

yaakov3415• 15 years ago

I might not be quite up to date, and I don't usually write extremely buggy code which compilers yell at, but have compilers really started warning on something like "vector_reference.push_back(&local_object);"? There are lots of ways to go wrong with unsafe memory access, and yes, there are tools to help you (things like valgrind help more than compiler warnings), but I think that the saying "hey, they gave you enough rope" is really unsatisfying. We've lived through 20 years of constant vulnerabilities because of these issues, and this only now starting to get sort of addressed. If virtually every team on the planet finds itself unable to use a certain tool "properly", then it's the tool which is being wrongly deployed, it's not the fault of everyone on the planet.

And I agree that the tool has a lot of usefulness in many places; obviously, you can't write system software without the ability to manipulate chunks of memory and the stack and everything else. But C++ is used as a universal programming language, and has tons of features which were not made for system programming, but for application programming. So on the one hand C++ has this extreme safety-oriented pedantry in which you have to decide if your design will have a reference to a const iterator or a const pointer or what, and on the other hand, you can cast that object to (void *) and write Stroustrup's picture to it.

Personally, I'd like to see a world in which the core system is written in a systems language like C/C++, and most libraries and all applications are managed code. Microsoft was working on something like this a few years ago, and I guess Android is sort of a step in that direction, but I think we won't get there for a long time. But it has to happen eventually, since we can't live with the vulnerabilities.

Reply

kragen8• 15 years ago

The thing is, all of the things you complain about in C++ are also true of machine code. Does that mean that machine code is unreasonable for writing secure applications or high-reliability applications? No. It just means you need to take extreme measures to verify that the machine code in your application doesn't have those problems. For example, you can use machine code emitted by a Scheme compiler that upholds type (and thus memory) safety. Or you can write a machine-checked proof that your machine code doesn't violate memory safety.

Stepanov points out that all the modern "safe" languages do nothing to prevent you from putting an infinite loop into your "high-reliability" application, which is every bit as fatal in an antilock brake control program as a buffer overflow would be.

He argues that the solution is to isolate unsafe operations — including, among other things, pointer arithmetic, recursion, and while loops — in a very small part of your code base, so that they have a chance of all being correct. And he argues that it doesn't matter whether the unsafe code is in a library or in the code generator of your compiler.

This seems plausible to me.

Unfortunately, I don't know of a practical programming language that allows you to factor all of your while loops and recursion into a small, non-expanding library. By contrast, the memory-safety problem is easily solvable at a substantial performance cost, and solvable at a minimal performance cost.

Reply

yaakov3415• 15 years ago

Sorry, but this sounds exactly like one of these comp-sci things which are perfectly true in theory and not usually true in practice. A compiler is usually written by a very strong team with an understanding of code correctness and techniques for ensuring it. Applications are written by average teams with a typically shaky understanding of software verification. A compiler usually has a much tighter specification. In the real world, it makes perfect sense to move as much of the burden of ensuring correctness as possible from the application to the compiler. Theoretically, it doesn't change anything, but practically, it helps a lot.

There are exceptions - embedded applications like anti-lock brake control systems are often written very close to the metal by strong teams which understand exactly how to ensure their correctness. They also have super-precise specifications. A compiler is often unnecessary or harmful here, and only introduces complexity. But this is not the case case for most of the millions of lines of code which keep being written in C/C++. I really think they would benefit from being written in a safer language. That's hard to justify rigorously, but I think that's part of the reason we saw C/C++ move from an absolutely dominant to merely a very important market share.

Reply

alok-g• 15 years ago

This may be a very naive question. Is having a separate segment for return addresses and stack data a useful option or an option at all?

Reply

city412• 15 years ago

Eric Lippert was one of the highlights of working at Microsoft. He was (and I'm sure, still is) very active on the internal C# mailing list. His answers are always very entertaining to read. He has a smugness that is deserved and not irritating (mostly :)), and inside the walls of MS he turns that smugness up quite a bit higher.

Reply

ericlippert• 15 years ago

I'm glad you enjoyed my answers; however, I am never intending to come across as smug. It is difficult to get across subtleties in an impoverished text-only medium; it has certainly been my experience that instructive and constructive criticism can easily be read as smugness. It's also been my experience that trying to deliberately make it sound less smug often just turns it into sounding like condescention. Text-based communication of technical issues is a hard problem and I do struggle with finding the right tone. Thanks for the feedback.

Reply

city412• 15 years ago

I don't think "smug" is quite the correct term. I meant nothing negative with my comment (and was teasing with the "mostly"). You do have an "air of authority" about your answers, but that authority is clearly earned. I enjoyed your answers on the C# mailing list quite a bit.

Reply

jamesgeck0• 15 years ago

I had a roommate in college who would write code like this. I (and several other people) tried to explain to him that he couldn't necessarily count on the pattern working all the time. His response was to say, "But it works here!" and continue abusing C++'s undefined behavior.

I stopped giving him help with his CS coursework in fairly short order.

Reply

thewisedude• 15 years ago

A good analogy no doubt! But you should be careful when using analogies. Every behavior of the analogy might not be applicable to the original problem.

Analogies can only help make people "understand" something. Normal brains try to relate things to what it has learnt so far. So analogies seem to help. Analogies in themselves are not scientific explanations obviously.

A scientific/rational explanation to the question posed by the user would be - C++ makes no promise about the behavior of the program when out-of scope C++ variable is used. Obviously this explanation -a simple one is quite less dramatic.

Reply

skrebbel• 15 years ago

if you can always legally access the book, which will for sure be available to you in that drawer, then the hotel key you stole must be a closure.

Reply

Q: Why can I access an out-of-scope C++ var? A: So you rent a hotel room...

Related Stories