Talk:Type safety - Knowledge

495:"The formal type-theoretic definition of type safety is considerably stronger than what is understood by most programmers." Who counted how many programmers understand type safety and in what way? This phrase communicates no new or even interesting information, beside being judgmental. Reword or remove? It seem to imply that there is a common confusion (needs not to state the percentage of programmers who are confused, enough two programmers to share the confusion for the confusion to be common) that type safety is an attribute of the environment executing the program than the language (which is basically what was said in the preceding sentence.) 489:

definitions. Something along the lines -- "Some definitions of Type Safety include a).. b)... c)... , whereas others consider that only d)... and e)... are really required for Type Safety". -- In this way there won't be the problem of trying to create a definition that everyone agrees on because, as you say, this may not be possible. But at least I would be able to get a simple idea up-front that would make me think "ah-ha I see what the article is about now, I can decide whether I need to read any more or not". If that woudl be possible I think it would go a long way towards helping the article.

627:

and deallocation of pointers in memory manually within code. In C, the only information you need to give the memory allocation function is how many bytes are required by the type that the pointer references, X, and then the function returns the first memory address allocated for type X, which is then cast to a pointer of X type and assigned to a variable. The danger here, however, is that you can potentially assign a number of bytes above or below what is required for X type, resulting in wasted memory when above, and undefined behavior when below. One possible outcome is a

631:; another is that, after assigning insufficient memory to one pointer, you assign memory to another pointer, but since the program control thinks the tail end of the memory required for the type of the first pointer is free, it allocates the next pointer starting at the first "free" address after. So now, we have two pointers to variables with overlapping memory blocks, and altering one may alter the other. These are the kinds of problems that automatic garbage collection attempts to eliminate, which is, I believe, key in understanding its relation to type safety. 1613:

really unsafe) and something that satisfies the formal definition to the letter. Based on that, I think that rather than just listing languages that fall into various categories, it may make more sense to discuss the issues associated with various languages. That's what I've tried to do (and I added a little bit about my favorite language). I think this list can grow: Java, for example, has quite a history of type safety bugs being discovered and patched. Most of them have to do with class loaders and things. Hopefully someone knowledgeable can fill that in.

1923:(1) the paragraph that started this discussion was about the relationship between type safety and memory safety, and the latter is an implementation issue (I think this was mentioned in a discussion much higher on this page), so meaningful discussion has to talk about implementation; and (2) we have to talk about any language on the level at which its semantics is defined. C is, if I'm not mistaken, defined in terms of its implementation on a machine; therefore it is impossible to say anything about its type system without referring to bits and things. 832:, it really doesn't make sense that Scheme is type-safe while being weakly typed. But I did some research. The article is a valid topic after all. I think we should emphasize more aspects of proof of programs in the article. It is not common (well for most of us) to prove a language is mathamtically type-safe. I am also suspecting this has something to do with proof-carrying code or such. Anyway, I am not into this topic and have no books or formal resources to tell much. MShonle is seeming knowledgable. So maybe we can just trust him? 1220:. You prove the point with your two alternative examples (you suggest something as complex as the mark operation; and your deep copy suggestion seems to be impractical). I think it's highly important that the article address the GC issue, for one reason it's completely non-intuititive but it's something every type systems reseracher must know. Also, please check out the Peirce quote, about three paragraphs above this message. He's one of the pre-eminent researchers in the area, and I'll take his word for it, as should the wikipedia. 1334:

To me, it no longer is manual memory management when it's GC (the qualifier "manual" is what ruined the meaning). Thus, I changed it to say "restrictions on the allocation and deallocation of memory". You can have GC, which certain does this (on the deallocation side), or region-based allocation (on the allocation side). Sorry for using strong words like "ruined", but I was quite miffed for you saying the article was "wrong" when it spoke the plain truth, and you simply disagreed with the style in which it was presented.

1872:, but it's not true of all languages by any means. If you reach into the memory of a running Java program and replace the contents of a variable of reference type (array or object) with random bits, you will most likely have introduced an error of a kind that could not possibly have occurred otherwise. On the other hand, if you do that to a C program, sure, you'll probably crash it, but not in a way that the language could ever have ruled out. Based on this, I say that the bits you wrote are 1056:. The first is fundamentally an implementation detail, and the second fundamentally a semantic detail. I assume you are not proposing to consider them to be the same problem. (Note that walking off the ends of arrays is possible even in type-safe languages like SML.) I await your specific citation from Pierce where the claim that "type safety requires garbage collection (or specialized memory management)" is substantiated. Page numbers will be fine. — 1559:

case that a number of languages are "mostly type safe" in the sense that they have some unsafe constructs but it's understood those are only to be used in desperate situations and even then very carefully. (Even if the language itself is safe, it's possible to link unsafe libraries into a program; this is mentioned in the article.) From a formal standpoint, of course, such languages are type unsafe and that's all there is to it.

1076:

exception is thrown. What's *not* ok is that the semantics of C never say what happens when you overwrite an array. What happens could affect even what code gets executed next. No one should ever claim that C is a typesafe language: calling it unsafe is not a value judgment on C itself. I've already made it clear in the article that garbage collectors are best written in languages like C (and Pierce makes the same point).

151: 74: 53: 1031:. Note that the result of the paper has been addressed in the article by saying "or specialized memory management". Either way, it's completely non-trivial and it's vital to the understand of security and typesafety to realize that introducing typing and avoiding all casts can still get you into trouble (unless you use GC like Java, C#, Scheme, ML, Smalltalk... or the other tricks). 22: 2356:

information at all - to C, where at the least, the compiler issues a warning during implicit conversion of types to verify programmer intent, to certain situations in C++ where use of reinterpret_cast is required to verify programmer intent. It's true that none of these situations are "strictly type-safe", but I feel they should be included for informational purposes.

399: 2005:

if you define assigning unreasonable (i.e., unused by the program: for writes, not requested for use; for reads, not initialized) values to pointers as type-unsafe, and assume that the only way to be memory-unsafe is to have a pointer pointing to something unreasonable, it's fairly clear that memory safety is a subset of type safety.

951:

std::string s ("hello") ; s += x ;". No compiler I am aware of will generate a warning on that line. Taking that integer and implicitly casting it to char* so that it can be concatenated onto the std::string is just plain wrong. Its just as wrong as doing "strcat (s, 1233456)" in C, but at least the C versions looks wrong.

1497:

then that means the language is not type safe. I'm a bit fuzzy on the semantics of the Ada constructs you mention, but certainly the fact that they are called "unchecked" suggests that they break type safety, making the statement that "Ada ... been shown to be type safe" highly suspicious to say the least.

1180:

To get around this dangling pointer problem you can either use garbage collection (common), or pools of object allocations where only structurally equivalent objects get allocated in the same memory regions (rarely used). If you don't fall into either GC or this (relatively) rare management, the language

1934:

Bottom line, do you disagree with my argument that type safety and memory safety are related, or do you only disagree with my use of the word "degenerate"? If the former, we should talk about that instead. If the latter, can we end this argument by changing "all but the most degenerate" to "most"?

1889:

distinguish between different types of the same size. Pointers are usually the same length as ints, at least at the moment, but syntactically the two are treated differently: attempting to, for instance, set an integer to a string will result in a compiler error, whereas setting a pointer to equal a

1702:

No, the program doesn't go boom. It raises an exception. There's a big difference, formally speaking: exceptions, the fact that you can catch and handle them, and the fact that they are raised in certain situations, are part of the language specification and hence completely predictable. You might

1333:

I'm glad we've reached consensus, because I'm tired of people reading this true, well-reasoned, logical, and interesting note on garbage collection and tring to reject it as non-factual. I felt that your intro sentence ruined the meaning by saying "place restrictions on ... manual memory management".

1110:

If you do not understand the dangling pointer problem, you should ask me questions (here, on the talk page) and we'll try to work it out. If you think that undefined behavior (such as deferencing a floating-point number) can still be typesafe, then that's a completely separate discussion. If you just

939:

Note, in it's present state the article discusses preservation and progress, near the very top of the article. Other readers should also see the conversation with Kaustuv and myself below that explains why GC is more than just an implementation detail. (To be fair, I would call it a technical detail,

695:

The C language could become type-safe if it had a complete semantic model. For example, if C code was translated into Scheme code, together with a model to simulate a machine, that definition of C would be type-safe provided that all of the semantics were complete. In C, you can change pointer values

538:

GC is not required for type safety. You can create a language with no memory deallocation whatsoever and it could still be type safe. Programs would just tend to run out of memory faster than otherwise which isn't pleasant, but isn't type unsafe either. More practically there are alternative memory

2370:

Does this strike anyone else as contradictory, or am I misunderstanding something? "Type safety is a property of the programming language, not of the programs themselves. For example, it is possible to write a safe program in a type-unsafe language." If it isn't a property of the program, how can it

2299:

The Saraswat paper purports to demonstrate a type-safety issue not in a specific implementation of the JVM, but in the JVM spec itself. If you wish to assert otherwise, please provide a reference. (Also, the current text implies that the issue no longer exists. If true — and I well believe it — then

2281:

of the Java Virtual Machine (which the Saraswat paper demonstrates) are a completely separate issue. However, to my knowledge, there never has been a formal proof that Java is type-safe (which, given the complexity of virtually all non-toy languages, is commonplace). That is, we shouldn't care that

2261:

On the other hand, this hole in the type system requires the use of multiple class loaders, so could be considered to be an unusual position for developers to get into. Under most circumstances Java is type safe. I might suggest that the article retains the claim that this is so, with a reference to

2004:

As for memory safety and type safety: insofar as "memory-safe" means "you can't point to something insane" and "type-safe" means "you can't assign insane values to variables", and insofar as pointers (where they exist) are variables, yes, type safety and memory safety do seem related. Specifically,

1640:. Put another way, if I am presented with the binary form of a third-party library written in Ada and don't have access to the source code, I can't just assume its authors did not use any Unchecked functions! What I think you mean, and what I have tried to express, is that type-safe programming is 1354:

The requirement of storage reclamation (garbage collection or otherwise) is entirely a pragmatic one, having nothing to do with semantics. You could perfectly well define a language that has bounded storage requirements (requiring fixed-size arrays, no pointers, and no recursion, even indirectly --

1237:

Yeah, I'm not saying we needn't mention GC, I'm saying the emphasis of the article was wrong, and is just as wrong in your updated revision. I've made some changes that I think improve that. As for the "GC best implemented in languages with pointer arithmetic", it seems irrelevant to the article, so

1202:

the question of how one ought to implement resource management in a language without those properties is of secondary concern (so it should be mentioned in passing, as my revision of the article does). In other words, the article should speak about language semantics; GC is an implementation detail.

1075:

Why would Pierce saying 2+2=4 be any more true than my saying it? I think I've fully demonstrated to you how garbage collection is an important element of typesafety. Note that when you go off the end of the array, if you get an exception that's perfectly fine: the semantics say what happens when an

859:

There is a relation to types, in that you don't want, in any way what-so-ever, to change the bits of a piece of data not sanctioned by the language. (Well, in the case of C, changing bits is sanctioned, but the behavior is undefined.) Matthias Felleisen has later said maybe his work should have been

626:

Because, usually, whenever a language has garbage collection, it implies that there is no direct manipulation of pointers in code, and that the language's built-in garbage collection handles it all. Whenever a language has no automatic garbage collection, such as in C, you must manage the allocation

457:

So I looked in the Definitions thinking I'd find some clues. But the definition starts with a nice little quote which doesn't really tell me (and, by the way, is obviously not true). So I keep reading and find that there are definitions in there, but definitions for Type Safety. Even a definition of

2409:

You have to look at the missing words: He speaks about writing a save program and not about not a type-save program. The typical weasel argument of an advocate of type-unsafe languages. And it is true - you just have to do all the safety services which a type-save language provides yourself. Only a

2326:

Sarawat provides a potential issue in the original Java Specification, which results in a possible vulnerability in a JVM implementing the early Java VM Specification. Sarawat's bug was addressed in the Java 1.2 specification, and all VMs implementing that specification or later do not exhibit the

1558:

In theory, type safety is a black and white issue -- once one has specified the type system, the run-time behavior and what it means to "go wrong", either the language is type safe or it's not. Based on the above I would say that Pascal and Ada both fail the test. In practice, I suppose it is the

1537:

For that matter, I don't think it is true that Pascal (the classic "type-safe language" that everyone hated because of its restrictiveness) is really type safe -- if I remember correctly, at least the classic Pascal language from the old days was not, due to a problem with variant records. I don't

1303:

How did my wording "ruin" the "meaning"? Regarding what I think is "wrong", I already explained my reasoning for what the emphasis of the article should be; read my first comment. You never replied to that part of my comment, though, so I didn't bother repeating myself. Anyway, I'm reasonably happy

1194:

I've rephrased the discussion of GC and type safety. Saying that type safety requires GC is strictly-speaking wrong, IMHO. Consider a hypothetical language which disallows pointer aliasing (so assigning one pointer to another would be a deep copy, not a shallow copy). Or a language in which when an

1179:

Just to be sure: Type safety is about programs "not going wrong." What I've described here is a way that, even if you can't manipulate the bits of a pointer directly (like typecasting in C allows) you can still make the program "blow up" through this complex dangling pointer example I've described.

739:

A complete semantic model can tell you something like "given this program and these inputs, and if I run it for this amount of steps, what is the value of everything?" Semantics can start with lamdba calculus style reduction rules. To prove Java's typesafety, there was a "feather weight Java" model

469:

What you say is true. The problem is that there is no generally agreed definition of the term, or even set of properties a program may have to be considered type safe. For instance, see the discussion on garbage collection below. The article is written from an idealised theoretical point of view

2066:

If you take random bits and copy them into a C int, you've broken type safety (unless you intended to create a random or otherwise arbitrary number, in which case copying the bits is just a way to generate a pseudorandom number). What results will be an integer, but a totally meaningless one. So

2056:

expect to get a sane value. The fact that you've broken memory safety by reading them means nothing, because I've already assumed the language is memory-unsafe and am trying to argue that it is consequently also type-unsafe. So in order for the argument that memory-unsafety breaks type safety to

1847:

type in the entire language that has a non-member. Int and float don't qualify, but is a sequence of bits a valid pointer value if it points to inaccessible memory? Can a value be a function pointer if it doesn't point to code? Perhaps in C, but not in languages that satisfy stronger notions of

1823:

Um, what sequence of bits is invalid in an average int, float, or pointer type? Are type systems that only have a few really basic types degenerate? C, for instance, only has integer (including chars), floating-point, array, and pointer types, doesn't it? Any sequence of bits of the appropriate

1496:

It depends on what you mean by "escape". If attempts to escape are checked at run time and fail if they don't make sense (as with Java casts, for example), then the language can be type safe. If it is possible to escape in ways that don't make sense, without the language implementation noticing,

1201:

discuss the question "what kinds of operations can we allow in a type-safe language?" As it turns out, one of the kinds of operations that need to be disallowed are some combinations of typical "pointer" types and manual memory management. Those restrictions should be the focus of the discussion —

1156:

problem: we allocate a cell holding a number, save a reference to it in some data structure, use it for a while, then deallocate it and allocate a new cell holding a boolean, possibly reusing the same storage. Now we can have two names for the same storage cell--one with type Ref Nat and the other

977:

The phrase "typically needs" is pure weasel wording. Either GC is necessary in a type safe language or not. If it is just one way to implement type safety, than the relationship is such that some type-safe languages do not have GC, and some non-type-safe language have GC. I think this qualifies as

675:

Thanks, I think linking to datatype is good idea. I also included in datatype a link to here. It's unfortunate that "type safe" can refer to either strong typing or "complete semantics." In academia, we only use type safety in the mathematical sense (one could say Scheme was strongly typed, but it

2205:

In the time that has passed since the last time I looked at this discussion, I've lost track of the reason I thought I had for saying "sequence of bits". What I really wanted to write at the time was "value" but for some reason I decided against it. I think "concept" is unnecessarily abstract.

1707:

on that exception to detect a certain perfectly normal condition in the program (but you'd hope no one really does this). In contrast, when a C++ cast goes wrong, you don't notice right away but the eventual result is implementation-dependent, that is, outside the specification of the language.

1635:

I just thought of another point. You have said many times that Ada's "default behavior" is type safe. I would have said the opposite: "By default," Ada compilers let you use the type-unsafe features whenever you want. Therefore, absent some assurance to the contrary (like what you may get from

1612:

Krischik, I hope you won't mind, but I reorganized your most recent contribution. I hope I preserved your intent, if not your language. I think what our conversation has shown is that when it comes to judging real-world languages and implementations, there is a large gray area between C (really

996:

It's very difficult for a general language to be typesafe and not have GC. I'll try to explain the concept here: Suppose that there was no GC in your language. Then that would mean you could have so-called dangling pointers. Now suppose you have a dangling pointer to an object that has an integer

985:

I think this is the thought trail used: type safety doesn't work with pointer arithmetic (see example). Lack of pointer arithmetic "usually" implies gc. Hence the relation. But you're right, it's not a strict claim. You can think of a language that's typesafe but doesn't have gc. Hell, think of a

1678:

Is it true that Java is believed to be type safe? Seems to me you can put an object of any class into a container, then pull it out as any other class. The first time you attempt to access any member, your program goes boom! If you believe that to be type safe you are working from a different

1373:

section, and became worried about the fact that the article defined type soundness in such a way as to completely rule out denotationally-specified languages (they have nothing analogous to Progress). W&F's paper describes some of the denotational-semantics-based notions of safety that were

1277:

As for your opinion about the emphasis of the article, perhaps you can provide some reasoning other than you saying that you think it's "wrong." I've already addressed your other concerns. Moreover, there is nothing factually wrong in the article as I mostly recently edited it. I'm going to also

926:

This article is full of highly questionable claims (Java and Scheme have been "mathematically proven" to be type-safe? Type safety requires a garbage collector?). There isn't even any mention of the key concepts in type-safety, viz. type-preservation and progress! I encourage editors to read the

904:

That's a good point. Perhaps it could be worded as "garbage collection or other restricted memory management systems (i.e., those memory systems without dangling pointers, or where dangling pointers can only point to objects of the same type)". Either way, the point is that people who make rules

751:

C++ is also unsafe, because you can change pointers. You would have to remove pointer arithmetic and others from C++, and give it garbage collection too, to even begin to make it safe. (This essentially gives you something closer to Java.) So as not to seem to be bashing C++, I mention C. I also

593:

On the GC article, it lists smart pointers as a form of garbage collection. However, reference counting has the flaw that a circularly link list can end up being "dead": unreachable, but still allocated. Reference counting has some pros over mark and sweep, but it can still lead to memory leaks

1930:

Sometimes you can just do the assignment, sometimes you have to do a cast, and sometimes you have to do other nasty tricks. This means we have to choose one of two possibilities: either C's type system is unsound, which I think qualifies it as degenerate, or it is sound but ultimately doesn't

1010:

I've updated the article. I also removed a rather snide, philistine comment that these claims about garbage collection were "dubious". I'm amazed how many times I've had to repeat this fact that appears repeatedly in computer science literature. I hope now that my saying "garbage collection or

488:

Thanks for the feedback. Without trying to create a 'perfect' definition of what Type Safety is, would it be possible to provide a loose definition. For example, is it possible to list the features of Type Safety that all definitions agree on? And then go on to list the differences between the

2248:

The "citation needed" claim that Java and Standard ML have type safety proofs is false. There is no type safety proof for any language officially recognized as Java. A type safety proof for a language that is a small delta from SML97 is ongoing (nearly complete, from what I know) work at CMU.

1741:

of a particular Java Virtual Machine (Sun's 1.1 JVM, in this case). While noteworthy, it has long since been fixed, and the page makes the incorrect implicit assertion that the problem was in Java, not a JVM. I'm going fix the page to note the problem, but remove the inference that Java isn't

1259:

The implementation note is not irrelevant. It serves three purposes, perhaps more: (1) it brings back the connection that you can have safe programs in type unsafe languages; (2) it shows that to create type safe systems you might need unsafe features; and thus (3) the article takes a neutral

950:

Another questionable claim is "C++ is more type-safe than C when used properly (avoiding the use of void pointers and casting between pointers of two types)". The long tradition of C like languages doing implicit casts between int and char* is inherently unsafe for code like "int x = 123456 ;

2355:

I'd like to add some general or introductory information to the article regarding the interpretation of type safety based on context. In my experience there are degrees of type safety, from "terrible" - such as in assembly, where it is typically impossible for the compiler to track any type

2233:

I just reverted a major edit that removed large amounts of content with insufficient explanation: the worst of these was the deletion of the entire section on memory management on the basis that "garbage collection has nothing to do with type safety", a subject that has already been argued

172: 1508:

for "Unchecked_Deallocation", "Unchecked_Convertion" and "Unchecked_Access". If none of those have been used then the type system has not been violated and as such is save. Ada serves a dual purpouse: The designers wanted a language with type savety which is suitable for

1000:

A non-GC language could only get around this problem by only allowing objects of the same type to be allocated in only the same locations. Reference counting could also be used, but reference counting is really considered a GC technique... but that's a whole other topic.

2469:. It must be remarked that all incorrect type coercions result in program failures - it is just that some unityped languages make these failures more evident (e.g., Python) while others attempt to disguise these failures as weird forms of "success" (e.g., JavaScript). 2047:

I argued in two directions. The bit pattern business was in the first direction, namely that memory-unsafe languages are also type-unsafe. Here the argument is that if you can read from an insane location, you can't expect to get a sane value. The catch is that if

884:

Actually, GC is not necessary for type-safety; GC is merely one mechanism for ensuring type-safe memory allocation. Region-based memory management, for example, is not usually thought of as garbage collection, but (with appropriate type system support) is type-safe.

997:

field. Now suppose that a new object is allocated on top of where this integer field uses to be, but instead of an integer field it's a pointer. If you now take the dangling pointer and change the integer field, you've actually arbitrarily changed the pointer value!

1876:

a valid value for the Java variable, since putting them there can cause the program to behave in very un-Java-like ways, even though you might say they are a valid value for the C variable, since you didn't break any language safety properties by introducing them.

1026:

Yes, it's in Pierce. I don't have my copy here, but you could probably find it by looking up garbage collection in the index. Besdies, haven't I already supplied enough reasons? Has reasoning gone out of fashion? Anyway, here's a whole paper that assumes the topic:

562:

Well, if you read the article, gc has tons to do with type safety. If you don't have gc, you can possibly change a pointer to anything you want. The confusion lies in that people use the term type-safety in different ways. That's part of the purpose of the article.

2444:

No, it is not contradictory. Type safety is a property of languages. It might be possible to write type-correct programs in type-unsafe languages, but it is not possible to write type-incorrect programs in type-safe languages. This is what type safety is about.

1896:

be reformulated (often more efficiently) via simple mapping such that all bit-patterns are valid, I don't think that the machine-level implementation of a language's types is a particularly good reason to declare it degenerate or not, or even trivial or not.

730:

Anyhow, what is a complete semantic model? From reading, it seems C lacks semantic mode while Java and Scheme, so C is not type-safe but Java and Scheme are. Is this simply means C has a mean to bypass a type system? What about C++? Is it as unsafe as C? --

1890:

string is perfectly valid. The difference is that the distinction is made at the compiler level, not at the machine level: the compiler will catch incorrect typing, but once you've reduced yourself to assembly, the actual bit-patterns will be identical.

2206:

Whether the assignment "would" break type safety or just "might" depends on just how the language happens to define the outcome -- a gray area on which many informal language definitions are silent. I will boldly change "sequence of bits" to "value".

2057:

hold water, there must exist some insane value that might be read from an insane location. My argument in the other direction, that certain kinds of type-unsafe behavior also break memory safety, had nothing to do with bits, triviality or degeneracy.

1944:

Well, the thing is, the types differ on the semantic level, not on the implementation level. If (hypothetically) you were to have a float and integer of the same bit length, any bit-pattern would be valid for either, but any given bit pattern (except

1195:

allocation is released, all pointers to the released storage are set to the null pointer. Both languages don't use GC, and while they are of dubious practical value, they also don't suffer from the specific type safety problem the article describes.

461:

I'm reading the article because I want a quick understanding of what Type Safety is. What is a Type? What is Type Safety. I can't find anything in the article that gives me a quick overview so I can decide which bits I want to carry on reading.

453:

I came to this page trying to find out about Type Safety. I read in the first paragraph that there are different definition of the term, but I'm not told what any of them are. I keep reading but I still don't find out what Type Safety is.

1374:

around before they did their thing; it seems like as long as this article is going to mention formal stuff we should at least leave room for someone who knows about denotational semantics to put in a word or two, so I tried to do that.

539:

management schemes, such as region based management, that allow type safety. I think whoever mentioned GC assumed that GC was the only alternative to C style malloc/free (or C++ new/delete) when in fact there are many alternatives.

837:

Anyway, true we have to put more contexts. Without background knowldge, I don't think the article makes much sense, like gc gurantees type-safety. It's probably true but the article needs to articulate more about why and how. --

530:, is that type rules are enforced rigidly. For example, you cannot performance integers addition over a value with a character datatype, even though it is perhaps possible on the level of the underlying computer architecture. -- 1260:

perspective toward C programmers. Many could read the article and think it was bashing C, when in reality it is saying "in order to implement systems with these properties that we're talking about, we need something like C."

745:

Making a machine model in Scheme inorder to run any program would essentially require emulating a machine (it's not quite that bad, but close). Because the machine is fixed, it's possible to have complete specifications and

1848:

type safety or memory safety. In that sense, yes, I would say C's type system is trivial and/or degenerate. Surely any system for "classifying" values is degenerate if it doesn't distinguish anything from anything else?

2007:

Or at least, that's how I see it, having read the article. There's no need to bring bit-patterns into it: even if the uninitialized data you're reading into the variable happens to match the bit-patterns allowed by type

2488:

This is a placeholder for a 'discuss' tag. I look forward to this discussion. My citation stems from Peyton-Jones' explanation of the GHC Core. My plan is to annotate my contribution with timestamps into the video clip.

905:

about strict typecasting (et cetera...) who think they have a type safe programming language are just fooling themselves if they don't have GC or anticipated it with some other form of restricted memory management.

1143:

allocation. We have not provided any primitives for freeing reference cells when they are no longer needed. Instead, like many modern languages (including ML and Java) we rely on the run-time system to perform

849:

To Dcoetzee and Takuya: I took a graduate-level class with one of the preeminent researchers behind type safety and type soundness, so this isn't really a topic that comes up for even a typical CS graduate

740:

that would give you L-calculus style reductions. But if I have a C program, it can change any memory it cares too, which sometimes can change the whole behavior of the program in an unpredictible manner.

676:

only has one type (ie. "object"), for example). The industry seems more to go with the other definition. It's not like one usage is "wrong", but in the literature it's good to know a distinction exists.

763:

Thank you very much. Now the article makes much more sense to me. I am now trying a bit to make the article more accessible. Please feel free to correct any of my errors including gramatical ones. --

1723:

Java is now (believed to be) type safe. Saraswat pointed out a bug in early versions of Java which was fixed by the introduction of loading constraints to prevent type spoofing. See the paper (

1446:

So more I read the discussion here so more if wonder if any "real" programming language can actualy archive "Type safety" as described here. That's unless they give up on the option of beeing

1355:

and yes, such languages do exist), or that fails when it runs out of storage (the cleanest semantics can't prevent that in general...). The wording needs to be changed to reflect all this. --

727:

Maybe I am not knowledgable enough to understand this. I read in your userpage that your Ph.D student so I don't doubt your expertise in computer science. I am just trying to understand some.

196: 650:

Why merge? Datatypes and type-safety are different topics. Might I suggest the type safety discussion of datatype gets placed in here? This page should discussion type safety as in this book

1455:

Garbage collectors are best implemented in languages that allow pointer arithmetic, so that the library that implements the collector itself is best done in a type-unsafe language like C.

2234:

extensively on this page. Other deletions included Robin Milner's famous slogan, the nod to denotational semantics and a slightly philosophical discussion of the meaning of "unsafe".

1152:

just a question of taste in language design: it is extremely difficult to achieve type safety in the presence of an explicit deallocation operation. The reason for this is the familiar

336: 1974:

Because anything can be summarized as a bit-pattern, but that's typically irrelevant to any particular point about the thing in question. It doesn't matter to type safety whether the

1926:

Obviously, C compilers do static type checking, and certain expressions (like your string-to-integer assignment example) are not allowed. But that doesn't change the fact that

869:

Whatever the case, there is an insightful piece of human knowledge when you realize garbage collection is essential for security, and therefore worthy of an encylopedia entry.

656:

Sorry I wasn't thinking carefully enough. I saw an article pop up suddenly without the context of datatype so I thought it was a result of a contributor who doesn't know about

253: 191: 2052:

values are considered sane, in the sense that anything you can possibly read from any location in memory is meaningful as a member of any type whatsoever, then of course you

1530:

Ada has ben supplied with two convertions. A checked convertions like in Java (even has the same functions style syntax) and Unchecked_Convertion which is a generic/template.

1824:

length would be valid for any of those, unless I'm missing something. (Well, a null pointer generally indicates a problem, but it's still a valid value, I should think.) —

1380:

Another thing I think this article should say but doesn't is: Only in a type-safe language are type annotations really meaningful. In C, you can declare a local variable

1865:, just not useful. If you tell the program to assign such a value to a pointer, it will dutifully do so, because those values are valid for the type within the language. 2540: 2185:

to that variable. Conversely, if the language is type unsafe to the extent of allowing an arbitrary integer to be used as a pointer, then it is clearly not memory safe.

124: 114: 1931:

distinguish anything (in the sense that every type has the same set of values, whether you phrase that in terms of bits or in syntactic terms) and is therefore trivial.

1369:

I originally just wanted to add the link to Wright and Felleisen, who are generally credited with having invented Preservation and Progress. I ended up creating a new

810:

Maybe it's just a bad term, but I find the idea of "type-safety" having apparently nothing to do with types rather suspect. Is this some kind of historical accident?

465:

The definition of Type Safety on the article "Strongly-typed programming language" is much clearer than the content of this article. A cleanup is definitely required

2128:

type systems satisfy this criterion.) If that language is memory-unsafe to the extent of allowing data to be copied from unallocated or uninitialized memory into a

1957:

of the type, which is to assign semantic value to bits and define interactions with differently-assigned bits. So I'd leave out mention of bit-patterns entirely.

1197:

While we can debate the GC issue endlessly, I think the more important point is that the article should not focus on this question in the first place. The article

2545: 2177: 2150: 2122: 2091: 2026: 1813: 1789: 1953:

something different in each type. I would view the precise bit-patterns allowed for a type to be a minor technicality; they aren't fundamentally related to the

1583:, and attempt to limit the use of unsafe languages to the garbage collector, system libraries, and as few other parts of the runtime system as they can manage. 2282:

Java hasn't been mathematically proved to be type-safe, as virtually all common program languages haven't either. It's enough to state that Java is type-safe

1545:

True indeed. Unlike Ada, Pascal did noch check the variant to be valid. In my Pascal time I often used variant record to perform an "Unchecked_Convertion". --

931:

on this very topic on the TYPES list. The present article only exposes a needless confusion of semantics (types) and implementation details (gc, etc.). —

90: 2535: 298: 981:

The explanation given is weak as it is couched completely in a single example, and makes no effort to give a definitive reason why GC may be required.

1861:

You're correct that some pointers might point to bad areas of memory, or might be null (which signifies no area of memory), but such values are still

940:

in the same way that, in a mathematical proof, division by zero is a "technical detail" that can be significant enough to make the proof invalid.) --

801:

That link actually talks about a different point that is not related to VM bugs, perse, but it should probably go under External Links or something.

2421:

yes, it sounds contradictory. Maybe he is not speaking about a type-save program, but the "For example..." words don't leads to that conclusion.

1682: 1737:

Also, the problem exposed by the OOPSLA paper wasn't a flaw in Java (the language), which fits the definition of type-safe. The flaw was in the

1475:

to be type save - and indeed: Ada's default behavior follows the two rules outlined in this module. However Ada does have escapes in the form of

272: 137: 81: 58: 1579:

By the way, I think it is safe to say that none of the many type safe languages in use today can be self-hosting. Most of them, however, do

958: 703:

The confusing part about this statement is that there's a real question as to whether C + complete semantic model would in fact still be C.

361: 1471:- especial the Chaper 2.6. "There is no escape". Question: Is a type save language allowed to have an escape? Example: I allways considered 2394: 710: 546: 1420:

And since Ph.D. students in programming languages seem to be playing a big role in this discussion, I'll mention that I am one too. :-)

1093:(BTW, just read the introduction or so to the paper. They make the same claims I do. Only *after* that do they talk about memory safety.) 2428: 1753: 1480: 244: 2465:

The notion of "type safety" in the so-called "dynamically typed" (really, unityped) languages is meaningless. Type safety is all about

2378: 1304:

with the current state of the article; I still disagree that the GC implementation note is worth including, but it's not a big deal.

2496: 1694: 1111:

want to see Pierce say it, well, wait until I get home to the book and perhaps we can stop wasting our time arguing who says 2+2=4.

502: 225: 2327:

flaw. Later discussions have found a couple of other class-loading issues, which have been subsequently fixed. All that said, the

1892:

So basically: given that any type system that prohibits certain types (of a given length) from containing certain bit-patterns can

1919:

I admit that looking at machine implementation is a bad way to judge languages. Normally I go around telling other people that.

2196: 2037: 1991: 1906: 1833: 317: 1476: 594:

anyway. A hybrid form of reference counting plus mark and sweep probably wouldn't be as fast as a modern garbage collector.

1843:

I wrote that. Perhaps "degenerate" is not the right word; "trivial" might be better. Note that the example only requires

664:

article. From the reading of the article, it seems the topic is different from a type system making the language safe. --

2073:. To see why, assume for purposes of discussion that a certain implementation of a certain language has some type, say 282: 163: 33: 2517:

YouTube: Into the core - squeezing Haskell into 9 constructors, by Simon Peyton-Jones (14 Sep 2016), Erlang Conference

292: 206: 1015:

Can you provide citations for this claim that type-safety requires garbage collection? Perhaps in Pierce's book? —

327: 89:

related articles on Knowledge. If you would like to participate, please visit the project page, where you can join

1580: 354: 2398: 2125: 1816: 1472: 962: 928: 660:

article. I guess I am not sure about this topic. My understading about type-safety is just safety described in

2254: 1436:

While I am a great advocate of type safetyI feel that the article is to much on the theoretical side of live.

1171:

I had a comment here before, but realised on second thought that it was garbage. Thanks for that reference. —

714: 550: 2432: 1757: 2382: 636: 506: 1724: 1468: 752:

added that little part about C being used to write gc so as to be sure that C wasn't being bashed either.

478:

does not have a lot to do with real life safety, although I'm sure the theoretical people will disagree).

431: 424: 2474: 2450: 1771:

assume for purposes of discussion that a certain implementation of a certain language has some type, say

2493: 1690: 263: 39: 1686: 2424: 2374: 2192: 2033: 1987: 1902: 1829: 1749: 1727: 954: 706: 542: 498: 2470: 2446: 1441:

Type safety is usually a requirement for any toy language proposed in programming language research.

21: 696:

to anything, but this can be simulated with a model of a memory system consisting of Scheme arrays.

439: 2332: 2331:

of Java is to be type-safe; like all other software in this world, bugs may compromise this goal.

2287: 1743: 1335: 1279: 1221: 1185: 1162: 1112: 1032: 1028: 1002: 941: 906: 870: 779: 753: 677: 595: 564: 1514: 632: 628: 526:

Is it so? I don't think gc has anything to do with type safety. The type safety, as described in

793:? I thought it helps understand what does it mean by bugs making Java's type system unsafe. -- 2336: 839: 794: 764: 732: 665: 610: 579: 531: 438:

Please help fix the broken anchors. You can remove this template after fixing the problems. |

182: 2490: 411: 234: 86: 2357: 2307: 2263: 2188: 2029: 1983: 1898: 1825: 1510: 479: 1139:"A last issue that we should mention before we move on formalizing references is storage 1625:

Well done - I think your approach ist better then mine - putting the issues up front. --

860:

called "complete specification" instead of type safety, but, well, no one calls it that.

1590:

I thought so too. And taking the strict rule I don't think it will ever be possible. --

308: 150: 2410:

human never does it as reliably as the automated process of a programming language. --

2162: 2135: 2107: 2076: 2011: 1798: 1774: 173:

Requested articles/Applied arts and sciences/Computer science, computing, and Internet

2529: 2411: 1664: 1661: 1626: 1591: 1567: 1546: 1487: 1356: 1148:, collecting and reusing cells that can no longer be reached by the program. This is 987: 813: 575: 1791:, such that there exists some sequence of bits (of the appropriate length) that is 1461: 1447: 1172: 1057: 1016: 932: 430:] The anchor (#Generic programming in .NET) is no longer available because it was 1398:

unless you have just created it yourself. In Java, on the other hand, if you say

1716: 1518: 821: 522:

Typically, a language needs to have garbage collection in order to be type-safe.

1377:

I have also clarified a bit how a dynamically-typed language can be type safe.

2516: 2301: 2235: 2207: 2058: 1969: 1936: 1928:

any value can end up in any variable of the correct size, regardless of type.

1878: 1849: 1713: 1651: 1616: 1603: 1423: 1305: 1239: 1203: 886: 1708:

This may be a different definition than yours, but it is the real definition.

791: 609:

Why can somebody change a pointer to anything he wants when there is no gc?

215: 1660:

Indeed true. I have kicked of some discussion about the issues involved at

651: 73: 52: 2253:

There is no type safety proof for Java because Java is not typesafe: see

2129: 829: 825: 661: 657: 527: 1648:

in the sense that use of the unsafe constructs is supposed to be rare.

419:

This article links to one or more target anchors that no longer exist.

1216:

Actually, we don't say type safety requires GC. We say it requires GC

2499: 2478: 2454: 2436: 2414: 2402: 2386: 2360: 2340: 2313: 2290: 2266: 2238: 2210: 2200: 2061: 2041: 1995: 1939: 1910: 1852: 1837: 1730: 1667: 1654: 1629: 1619: 1606: 1594: 1570: 1549: 1490: 1426: 1359: 1338: 1308: 1282: 1242: 1224: 1206: 1188: 1165: 1115: 1035: 1005: 990: 966: 944: 909: 718: 640: 613: 554: 510: 393: 291:

Find pictures for the biographies of computer scientists (see

15: 1636:

grepping the code), any given Ada program should be presumed

1460:

Actualy most languages mentioned here as type save are not

1390:

but, because C is not type-safe you can never be sure that

1029:

Memory Safety Without Runtime Checks or Garbage Collection

1011:

specialized memory management" will clear up any doubts.

1278:

change some of your wordings, which ruined the meaning.

2286:, which is all we really care about in this article. 2152:, then it is not type safe, because such an operation 2028:, you've still broken memory safety by reading them. — 1968:, then how can you expect to leave bit patterns out? 1726:) by Liang and Bracha from OOPSLA'98 for more details. 574:

Oops, I was thinking of strong typing. Ok, what about

2165: 2138: 2110: 2079: 2014: 1801: 1777: 578:? Doesn't it make sure the pointer is not broken? -- 1663:. This article got me thinking about some issues. -- 85:, a collaborative effort to improve the coverage of 2273:As noted above, Java (the language) most certainly 2244:

Java and Standard ML do not have type safety proofs

2171: 2144: 2116: 2085: 2020: 1807: 1783: 1566:I guess I have to think about that for a while. -- 1469:Why Pascal is Not My Favorite Programming Language 197:Computer science articles needing expert attention 1978:are the same or different, it matters that the 1417:(or of one of its subclasses) will be illegal. 1885:See, the thing is, C classification of values 1052:, which I would claim is quite different from 337:WikiProject Computer science/Unreferenced BLPs 820:Apparently, the article is in the context of 8: 2095:sequence of bits (of the appropriate length) 2371:be possible to write a type-safe program? 2069:Type safety is closely linked to so-called 1964:" of a type is to assign semantic value to 254:Computer science articles without infoboxes 192:Computer science articles needing attention 158:Here are some tasks awaiting attention: 132: 47: 2351:Degrees or interpretations of type safety 2164: 2137: 2109: 2078: 2013: 1800: 1776: 1413:being anything other than an instance of 1128:Here is the much-wanted quote from Pierce 2541:Mid-importance Computer science articles 2393:Yes, it seems contradictory to me too.-- 2509: 1538:know about more modern Pascal dialects. 1513:programming as well. But it seams that 1218:or some other memory management heroics 986:typesafe language without heap memory! 423:] The anchor (#object class) has been 49: 19: 2300:it should have a reference as well.) — 470:(which is a clue to the fact that the 99:Knowledge:WikiProject Computer science 2546:WikiProject Computer science articles 1819:type systems satisfy this criterion.) 102:Template:WikiProject Computer science 7: 79:This article is within the scope of 1409:then anything that might result in 458:'Type' would be good, but alas no. 38:It is of interest to the following 1644:to be the default behavior of Ada 1048:The paper you mention talks about 517:Garbage collection and type safety 273:Timeline of computing 2020–present 14: 2536:C-Class Computer science articles 299:Computing articles needing images 1132:Types and Programming Languages, 397: 149: 72: 51: 20: 2461:Type safety and "strong typing" 1868:As I acknowledged, that's true 1697:) 22:35, 26 January 2006 (UTC) 1679:definition of the term than I. 119:This article has been rated as 2239:21:55, 22 September 2006 (UTC) 2211:18:44, 15 September 2006 (UTC) 2093:, such that there exists some 1: 2500:18:06, 14 December 2017 (UTC) 1521:are indeed mutualy exclusive. 353:Tag all relevant articles in 93:and see a list of open tasks. 2437:08:44, 2 December 2009 (UTC) 2341:10:05, 30 January 2012 (UTC) 2277:type-safe. Bugs in specific 1731:15:51, 12 October 2007 (UTC) 1717:01:03, 27 January 2006 (UTC) 1668:07:12, 27 January 2006 (UTC) 1655:22:31, 26 January 2006 (UTC) 1630:07:12, 27 January 2006 (UTC) 1620:01:22, 27 January 2006 (UTC) 1607:20:57, 25 January 2006 (UTC) 1595:07:24, 26 January 2006 (UTC) 1571:07:24, 26 January 2006 (UTC) 1550:07:24, 26 January 2006 (UTC) 1491:10:18, 25 January 2006 (UTC) 1427:00:04, 24 January 2006 (UTC) 1360:00:36, 27 January 2006 (UTC) 973:Garbage Collection Confusion 967:00:51, 21 January 2011 (UTC) 778:I've made some minor edits. 614:09:20, 2 November 2007 (UTC) 362:WikiProject Computer science 138:WikiProject Computer science 82:WikiProject Computer science 2415:16:21, 10 August 2009 (UTC) 2387:00:53, 5 October 2008 (UTC) 1673: 945:02:34, 8 January 2006 (UTC) 293:List of computer scientists 2562: 2361:20:52, 8 August 2008 (UTC) 1703:even imagine a programmer 797:00:22, Apr 18, 2004 (UTC) 735:23:41, Apr 17, 2004 (UTC) 534:23:13, Apr 17, 2004 (UTC) 511:11:27, 28 April 2012 (UTC) 125:project's importance scale 2479:15:15, 27 June 2013 (UTC) 2455:15:08, 27 June 2013 (UTC) 2403:20:09, 29 July 2009 (UTC) 2314:14:36, 21 June 2011 (UTC) 2291:21:43, 19 June 2011 (UTC) 2201:03:44, 11 June 2006 (UTC) 1996:03:44, 11 June 2006 (UTC) 1746:21:20, 19 June 2011 UTC 1504:Well in Ada is a case of 1365:New "Definitions" section 935:20:06, 2004 Aug 17 (UTC) 842:17:10, Apr 18, 2004 (UTC) 816:17:01, 18 Apr 2004 (UTC) 767:00:14, Apr 18, 2004 (UTC) 719:17:04, 5 April 2011 (UTC) 668:23:29, Apr 17, 2004 (UTC) 582:23:29, Apr 17, 2004 (UTC) 555:17:02, 5 April 2011 (UTC) 355:Category:Computer science 131: 118: 105:Computer science articles 67: 46: 2267:09:58, 1 June 2007 (UTC) 2062:00:07, 26 May 2006 (UTC) 2042:05:52, 25 May 2006 (UTC) 1940:04:41, 24 May 2006 (UTC) 1911:02:59, 24 May 2006 (UTC) 1853:22:30, 21 May 2006 (UTC) 1838:16:44, 19 May 2006 (UTC) 1339:02:41, 15 May 2005 (UTC) 1309:02:21, 15 May 2005 (UTC) 1283:01:51, 15 May 2005 (UTC) 1243:00:55, 15 May 2005 (UTC) 1225:18:00, 14 May 2005 (UTC) 1207:14:12, 14 May 2005 (UTC) 1189:21:59, 13 May 2005 (UTC) 1175:01:50, 2005 May 14 (UTC) 1166:01:31, 14 May 2005 (UTC) 1116:23:22, 13 May 2005 (UTC) 1060:23:10, 2005 May 13 (UTC) 1036:22:57, 13 May 2005 (UTC) 1019:22:27, 2005 May 13 (UTC) 889:07:14, 18 Aug 2004 (UTC) 873:20:37, 18 Apr 2004 (UTC) 790:Why did you remove this 782:00:21, 18 Apr 2004 (UTC) 756:23:55, 17 Apr 2004 (UTC) 687:Complete semantic model? 680:23:39, 17 Apr 2004 (UTC) 598:23:59, 17 Apr 2004 (UTC) 567:23:16, 17 Apr 2004 (UTC) 357:and sub-categories with 2484:Type safety of System F 2104:a legitimate member of 1795:a legitimate member of 1766:Degenerate type system? 1394:points to a legitimate 1238:I've removed it again. 1006:22:14, 7 May 2005 (UTC) 991:19:11, 7 May 2005 (UTC) 910:19:20, 8 May 2005 (UTC) 641:06:27, 8 May 2014 (UTC) 2173: 2146: 2118: 2087: 2022: 1821: 1809: 1785: 1481:Unchecked_Deallocation 425:deleted by other users 318:Computer science stubs 28:This article is rated 2174: 2147: 2124:. (All but the most 2119: 2088: 2023: 1815:. (All but the most 1810: 1786: 1769: 1685:comment was added by 2163: 2136: 2108: 2077: 2012: 1799: 1775: 1477:Unchecked_conversion 1385:struct something *x; 1157:with type Ref Bool." 136:Things you can help 2467:preventing failures 1483:(and some others). 1467:This reminds me of 922:Questionable claims 2229:Reverted deletions 2169: 2142: 2114: 2083: 2018: 1805: 1781: 1674:Java's type safety 1515:System programming 1432:Theory vs. Praxis. 1154:dangling reference 1146:garbage collection 629:segmentation fault 34:content assessment 2427:comment added by 2377:comment added by 2311: 2172:{\displaystyle t} 2145:{\displaystyle t} 2117:{\displaystyle t} 2086:{\displaystyle t} 2021:{\displaystyle t} 1808:{\displaystyle t} 1784:{\displaystyle t} 1752:comment added by 1698: 957:comment added by 828:. In the line of 806:Type safety/types 709:comment added by 545:comment added by 501:comment added by 446: 445: 432:deleted by a user 414:in most browsers. 392: 391: 388: 387: 384: 383: 380: 379: 376: 375: 2553: 2519: 2514: 2439: 2389: 2305: 2178: 2176: 2175: 2170: 2151: 2149: 2148: 2143: 2123: 2121: 2120: 2115: 2092: 2090: 2089: 2084: 2067:what if it said: 2027: 2025: 2024: 2019: 1814: 1812: 1811: 1806: 1790: 1788: 1787: 1782: 1761: 1680: 1416: 1412: 1404: 1397: 1393: 1386: 1134:2002. Page 158: 969: 721: 557: 513: 449:Cleanup Required 440:Reporting errors 401: 400: 394: 366: 360: 235:Computer science 164:Article requests 153: 146: 145: 133: 107: 106: 103: 100: 97: 96:Computer science 87:Computer science 76: 69: 68: 63: 59:Computer science 55: 48: 31: 25: 24: 16: 2561: 2560: 2556: 2555: 2554: 2552: 2551: 2550: 2526: 2525: 2524: 2523: 2522: 2515: 2511: 2486: 2463: 2422: 2372: 2368: 2353: 2312: 2279:implementations 2246: 2231: 2186: 2184: 2181: 2161: 2160: 2158: 2155: 2134: 2133: 2106: 2105: 2099: 2096: 2075: 2074: 2010: 2009: 1982:is different. — 1797: 1796: 1773: 1772: 1768: 1747: 1728:Glyn normington 1681:—The preceding 1676: 1511:Embedded system 1434: 1414: 1410: 1402: 1395: 1391: 1384: 1367: 975: 959:150.101.204.108 952: 924: 814:Derrick Coetzee 808: 704: 691:Some question: 689: 540: 519: 496: 451: 442: 417: 416: 415: 398: 372: 369: 364: 358: 346:Project-related 341: 322: 303: 277: 258: 239: 220: 201: 177: 104: 101: 98: 95: 94: 61: 32:on Knowledge's 29: 12: 11: 5: 2559: 2557: 2549: 2548: 2543: 2538: 2528: 2527: 2521: 2520: 2508: 2507: 2503: 2485: 2482: 2462: 2459: 2458: 2457: 2441: 2440: 2418: 2417: 2406: 2405: 2395:151.202.239.74 2367: 2366:Contradictory? 2364: 2352: 2349: 2348: 2347: 2346: 2345: 2344: 2343: 2319: 2318: 2317: 2316: 2304: 2294: 2293: 2270: 2269: 2258: 2257: 2245: 2242: 2230: 2227: 2226: 2225: 2224: 2223: 2222: 2221: 2220: 2219: 2218: 2217: 2216: 2215: 2214: 2213: 2182: 2179: 2168: 2156: 2153: 2141: 2113: 2097: 2094: 2082: 2068: 2017: 2002: 2001: 2000: 1999: 1998: 1948: 1932: 1924: 1883: 1882: 1881: 1856: 1855: 1804: 1780: 1767: 1764: 1763: 1762: 1739:implementation 1734: 1733: 1720: 1719: 1710: 1709: 1675: 1672: 1671: 1670: 1633: 1632: 1610: 1609: 1600: 1599: 1598: 1597: 1585: 1584: 1576: 1575: 1574: 1573: 1561: 1560: 1555: 1554: 1553: 1552: 1540: 1539: 1534: 1533: 1532: 1531: 1525: 1524: 1523: 1522: 1499: 1498: 1458: 1457: 1444: 1443: 1433: 1430: 1407: 1406: 1388: 1387: 1366: 1363: 1352: 1351: 1350: 1349: 1348: 1347: 1346: 1345: 1344: 1343: 1342: 1341: 1320: 1319: 1318: 1317: 1316: 1315: 1314: 1313: 1312: 1311: 1292: 1291: 1290: 1289: 1288: 1287: 1286: 1285: 1268: 1267: 1266: 1265: 1264: 1263: 1262: 1261: 1250: 1249: 1248: 1247: 1246: 1245: 1230: 1229: 1228: 1227: 1211: 1210: 1177: 1176: 1160: 1159: 1130:, in his book 1125: 1124: 1123: 1122: 1121: 1120: 1119: 1118: 1101: 1100: 1099: 1098: 1097: 1096: 1095: 1094: 1084: 1083: 1082: 1081: 1080: 1079: 1078: 1077: 1066: 1065: 1064: 1063: 1062: 1061: 1041: 1040: 1039: 1038: 1021: 1020: 994: 993: 988:Wouter Lievens 974: 971: 948: 947: 923: 920: 919: 918: 917: 916: 915: 914: 913: 912: 895: 894: 893: 892: 891: 890: 877: 876: 875: 874: 864: 863: 862: 861: 854: 853: 852: 851: 844: 843: 834: 833: 807: 804: 803: 802: 788: 787: 786: 785: 784: 783: 771: 770: 769: 768: 758: 757: 748: 747: 742: 741: 725: 724: 723: 722: 711:204.14.239.222 698: 697: 688: 685: 684: 683: 682: 681: 670: 669: 648: 647: 646: 645: 644: 643: 619: 618: 617: 616: 604: 603: 602: 601: 600: 599: 586: 585: 584: 583: 569: 568: 559: 558: 547:204.14.239.222 524: 523: 518: 515: 493: 492: 491: 490: 483: 482: 450: 447: 444: 443: 437: 436: 435: 428: 412:case-sensitive 406: 405: 404: 402: 390: 389: 386: 385: 382: 381: 378: 377: 374: 373: 371: 370: 368: 367: 350: 342: 340: 339: 333: 323: 321: 320: 314: 304: 302: 301: 296: 288: 278: 276: 275: 269: 259: 257: 256: 250: 240: 238: 237: 231: 221: 219: 218: 212: 202: 200: 199: 194: 188: 178: 176: 175: 169: 157: 155: 154: 142: 141: 129: 128: 121:Mid-importance 117: 111: 110: 108: 91:the discussion 77: 65: 64: 62:Mid‑importance 56: 44: 43: 37: 26: 13: 10: 9: 6: 4: 3: 2: 2558: 2547: 2544: 2542: 2539: 2537: 2534: 2533: 2531: 2518: 2513: 2510: 2506: 2502: 2501: 2498: 2495: 2492: 2483: 2481: 2480: 2476: 2472: 2468: 2460: 2456: 2452: 2448: 2443: 2442: 2438: 2434: 2430: 2429:79.154.168.94 2426: 2420: 2419: 2416: 2413: 2408: 2407: 2404: 2400: 2396: 2392: 2391: 2390: 2388: 2384: 2380: 2376: 2365: 2363: 2362: 2359: 2350: 2342: 2338: 2334: 2330: 2325: 2324: 2323: 2322: 2321: 2320: 2315: 2310: 2309: 2303: 2298: 2297: 2296: 2295: 2292: 2289: 2285: 2280: 2276: 2272: 2271: 2268: 2265: 2260: 2259: 2255: 2252: 2251: 2250: 2243: 2241: 2240: 2237: 2228: 2212: 2209: 2204: 2203: 2202: 2198: 2194: 2190: 2166: 2159:assign a non- 2139: 2131: 2127: 2111: 2103: 2080: 2072: 2071:memory safety 2065: 2064: 2063: 2060: 2055: 2051: 2046: 2045: 2044: 2043: 2039: 2035: 2031: 2015: 2003: 1997: 1993: 1989: 1985: 1981: 1977: 1973: 1972: 1971: 1967: 1963: 1960:Hm. If the " 1959: 1958: 1956: 1952: 1947:0000 0000 ... 1946: 1943: 1942: 1941: 1938: 1933: 1929: 1925: 1922: 1918: 1915: 1914: 1913: 1912: 1908: 1904: 1900: 1895: 1888: 1884: 1880: 1875: 1871: 1867: 1866: 1864: 1860: 1859: 1858: 1857: 1854: 1851: 1846: 1842: 1841: 1840: 1839: 1835: 1831: 1827: 1820: 1818: 1802: 1794: 1778: 1765: 1759: 1755: 1754:98.210.108.64 1751: 1745: 1740: 1736: 1735: 1732: 1729: 1725: 1722: 1721: 1718: 1715: 1712: 1711: 1706: 1701: 1700: 1699: 1696: 1692: 1688: 1684: 1669: 1666: 1662: 1659: 1658: 1657: 1656: 1653: 1649: 1647: 1643: 1639: 1631: 1628: 1624: 1623: 1622: 1621: 1618: 1614: 1608: 1605: 1602: 1601: 1596: 1593: 1589: 1588: 1587: 1586: 1582: 1578: 1577: 1572: 1569: 1565: 1564: 1563: 1562: 1557: 1556: 1551: 1548: 1544: 1543: 1542: 1541: 1536: 1535: 1529: 1528: 1527: 1526: 1520: 1516: 1512: 1507: 1503: 1502: 1501: 1500: 1495: 1494: 1493: 1492: 1489: 1484: 1482: 1478: 1474: 1470: 1465: 1463: 1456: 1453: 1452: 1451: 1449: 1442: 1439: 1438: 1437: 1431: 1429: 1428: 1425: 1421: 1418: 1401: 1400: 1399: 1383: 1382: 1381: 1378: 1375: 1372: 1364: 1362: 1361: 1358: 1340: 1337: 1332: 1331: 1330: 1329: 1328: 1327: 1326: 1325: 1324: 1323: 1322: 1321: 1310: 1307: 1302: 1301: 1300: 1299: 1298: 1297: 1296: 1295: 1294: 1293: 1284: 1281: 1276: 1275: 1274: 1273: 1272: 1271: 1270: 1269: 1258: 1257: 1256: 1255: 1254: 1253: 1252: 1251: 1244: 1241: 1236: 1235: 1234: 1233: 1232: 1231: 1226: 1223: 1219: 1215: 1214: 1213: 1212: 1209: 1208: 1205: 1200: 1193: 1192: 1191: 1190: 1187: 1183: 1174: 1170: 1169: 1168: 1167: 1164: 1158: 1153: 1149: 1145: 1140: 1137: 1136: 1135: 1133: 1129: 1117: 1114: 1109: 1108: 1107: 1106: 1105: 1104: 1103: 1102: 1092: 1091: 1090: 1089: 1088: 1087: 1086: 1085: 1074: 1073: 1072: 1071: 1070: 1069: 1068: 1067: 1059: 1055: 1051: 1050:memory safety 1047: 1046: 1045: 1044: 1043: 1042: 1037: 1034: 1030: 1025: 1024: 1023: 1022: 1018: 1014: 1013: 1012: 1008: 1007: 1004: 998: 992: 989: 984: 983: 982: 979: 978:irrelevant. 972: 970: 968: 964: 960: 956: 946: 943: 938: 937: 936: 934: 930: 927:illuminating 921: 911: 908: 903: 902: 901: 900: 899: 898: 897: 896: 888: 883: 882: 881: 880: 879: 878: 872: 868: 867: 866: 865: 858: 857: 856: 855: 848: 847: 846: 845: 841: 836: 835: 831: 827: 823: 819: 818: 817: 815: 811: 805: 800: 799: 798: 796: 792: 781: 777: 776: 775: 774: 773: 772: 766: 762: 761: 760: 759: 755: 750: 749: 744: 743: 738: 737: 736: 734: 728: 720: 716: 712: 708: 702: 701: 700: 699: 694: 693: 692: 686: 679: 674: 673: 672: 671: 667: 663: 659: 655: 654: 653: 652: 642: 638: 634: 633:WastedMeerkat 630: 625: 624: 623: 622: 621: 620: 615: 612: 608: 607: 606: 605: 597: 592: 591: 590: 589: 588: 587: 581: 577: 576:smart pointer 573: 572: 571: 570: 566: 561: 560: 556: 552: 548: 544: 537: 536: 535: 533: 529: 521: 520: 516: 514: 512: 508: 504: 500: 487: 486: 485: 484: 481: 477: 473: 468: 467: 466: 463: 459: 455: 448: 441: 433: 429: 426: 422: 421: 420: 413: 409: 403: 396: 395: 363: 356: 352: 351: 349: 347: 343: 338: 335: 334: 332: 330: 329: 324: 319: 316: 315: 313: 311: 310: 305: 300: 297: 294: 290: 289: 287: 285: 284: 279: 274: 271: 270: 268: 266: 265: 260: 255: 252: 251: 249: 247: 246: 241: 236: 233: 232: 230: 228: 227: 222: 217: 214: 213: 211: 209: 208: 203: 198: 195: 193: 190: 189: 187: 185: 184: 179: 174: 171: 170: 168: 166: 165: 160: 159: 156: 152: 148: 147: 144: 143: 139: 135: 134: 130: 126: 122: 116: 113: 112: 109: 92: 88: 84: 83: 78: 75: 71: 70: 66: 60: 57: 54: 50: 45: 41: 35: 27: 23: 18: 17: 2512: 2504: 2487: 2471:Eduardo León 2466: 2464: 2447:Eduardo León 2379:96.242.156.9 2369: 2354: 2328: 2306: 2283: 2278: 2274: 2262:this paper. 2247: 2232: 2101: 2070: 2053: 2049: 2006: 1979: 1976:bit-patterns 1975: 1965: 1961: 1954: 1950: 1927: 1920: 1916: 1893: 1891: 1886: 1873: 1869: 1862: 1844: 1822: 1792: 1770: 1748:— Preceding 1742:type-safe. 1738: 1704: 1677: 1650: 1645: 1641: 1637: 1634: 1615: 1611: 1505: 1485: 1466: 1459: 1454: 1445: 1440: 1435: 1422: 1419: 1408: 1389: 1379: 1376: 1370: 1368: 1353: 1217: 1198: 1196: 1181: 1178: 1161: 1155: 1151: 1147: 1142: 1138: 1131: 1127: 1126: 1053: 1049: 1009: 999: 995: 980: 976: 949: 925: 812: 809: 789: 746:determinism. 729: 726: 690: 649: 611:Glass Tomato 525: 497:— Preceding 494: 475: 471: 464: 460: 456: 452: 418: 410:Anchors are 407: 345: 344: 328:Unreferenced 326: 325: 307: 306: 281: 280: 262: 261: 243: 242: 224: 223: 205: 204: 181: 180: 162: 161: 120: 80: 40:WikiProjects 2497:| contribs) 2491:Ancheta Wis 2423:—Preceding 2373:—Preceding 1687:209.4.89.67 1646:programmers 1519:Type safety 1462:self-hosted 1448:self-hosted 1371:Definitions 1054:type safety 953:—Preceding 822:type theory 705:—Preceding 541:—Preceding 503:109.65.38.7 2530:Categories 2505:References 2358:Reinderien 2264:JoeKearney 2189:Simetrical 2126:degenerate 2030:Simetrical 1984:Simetrical 1899:Simetrical 1826:Simetrical 1817:degenerate 1184:typesafe. 929:discussion 480:Derek farn 2284:by design 1581:bootstrap 1415:Something 1403:Something 1396:something 476:type safe 216:Computing 2425:unsigned 2412:Krischik 2375:unsigned 2197:contribs 2132:of type 2130:variable 2100:that is 2038:contribs 1992:contribs 1949:) would 1907:contribs 1834:contribs 1750:unsigned 1695:contribs 1683:unsigned 1665:Krischik 1642:supposed 1627:Krischik 1592:Krischik 1568:Krischik 1547:Krischik 1488:Krischik 1357:Macrakis 955:unsigned 850:student. 830:datatype 826:datatype 707:unsigned 662:datatype 658:datatype 543:unsigned 528:datatype 499:unsigned 264:Maintain 207:Copyedit 2333:Trims2u 2288:trims2u 2183:meaning 2098:concept 1980:meaning 1917:Touché. 1744:trims2u 1705:relying 1336:MShonle 1280:MShonle 1222:MShonle 1186:MShonle 1173:Kaustuv 1163:MShonle 1113:MShonle 1058:Kaustuv 1033:MShonle 1017:Kaustuv 1003:MShonle 942:MShonle 933:Kaustuv 907:MShonle 871:MShonle 780:MShonle 754:MShonle 678:MShonle 596:MShonle 565:MShonle 434:before. 427:before. 245:Infobox 183:Cleanup 123:on the 30:C-class 2329:design 1962:nature 1955:nature 1894:always 1638:unsafe 1199:should 824:, not 226:Expand 36:scale. 2494:(talk 2302:Ruakh 2236:Cjoev 2208:Cjoev 2180:value 2157:would 2154:might 2059:Cjoev 1970:Cjoev 1937:Cjoev 1879:Cjoev 1863:valid 1850:Cjoev 1714:Cjoev 1652:Cjoev 1617:Cjoev 1604:Cjoev 1424:Cjoev 1306:Neilc 1240:Neilc 1204:Neilc 1182:isn't 887:k.lee 309:Stubs 283:Photo 140:with: 2475:talk 2451:talk 2433:talk 2399:talk 2383:talk 2337:talk 2308:TALK 2193:talk 2034:talk 1988:talk 1966:bits 1951:mean 1921:But: 1903:talk 1887:does 1870:in C 1830:talk 1758:talk 1691:talk 1517:and 1479:and 963:talk 840:Taku 795:Taku 765:Taku 733:Taku 715:talk 666:Taku 637:talk 580:Taku 551:talk 532:Taku 507:talk 472:safe 408:Tip: 2102:not 2054:can 2050:all 1874:not 1845:one 1793:not 1506:ing 1473:Ada 1150:not 474:in 115:Mid 2532:: 2489:-- 2477:) 2453:) 2435:) 2401:) 2385:) 2339:) 2275:is 2199:) 2195:• 2040:) 2036:• 1994:) 1990:• 1909:) 1905:• 1836:) 1832:• 1760:) 1693:• 1486:-- 1464:. 1450:: 1405:x; 1141:de 965:) 717:) 639:) 553:) 509:) 365:}} 359:{{ 2473:( 2449:( 2431:( 2397:( 2381:( 2335:( 2256:. 2191:( 2187:— 2167:t 2140:t 2112:t 2081:t 2032:( 2016:t 1986:( 1901:( 1897:— 1828:( 1803:t 1779:t 1756:( 1689:( 1411:x 1392:x 961:( 713:( 635:( 549:( 505:( 348:: 331:: 312:: 295:) 286:: 267:: 248:: 229:: 210:: 186:: 167:: 127:. 42::

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Index