2

When you access an array out of bounds, for example:

int numbers[2];

numbers[2] = 12345;  // here we are accessing the array out of bounds

Is the above considered a violation of type safety or a violation of memory safety?

Or is it a violation of both? the reason why I think it may be a violation of both is because this article may be saying that memory safety is a subset of type safety:

C and C++: not type safe. C’s standard type system does not rule out programs that the standard (and common practice) considers meaningless, e.g., programs that write off the end of a buffer. 1 So, for C, well typed programs can go wrong. C++ is (morally) a superset of C, and so it inherits C’s lack of type safety.

The article also have the following note for the 1 above:

C is also not memory safe; in effect, the undefined behaviors that memory safety rules out are a subset of the undefined behaviors ruled out by type safety.

user4582812
  • 591
  • 1
  • 4
  • 16
  • 5
    AFAIK the C/C++ standards don't make such a distinction. UB is UB, that's all. – HolyBlackCat Jul 07 '20 at 13:33
  • 1
    It's memory safety violation for sure. You *might* stretch the "type safety" definition to try and cover this, but I don't see a reason to do so. – Eugene Sh. Jul 07 '20 at 13:33
  • *"... and so it inherits C’s lack of type safety."* That's not correct. c++ adds type safety. – cigien Jul 07 '20 at 13:35
  • Type safety violation: accessing the object out of bounds is not caught by the compiler. Memory safety violation: accessing memory outside the bounds of an object is not (necessarily) caught by the run-time system. Could this view help? – Paul Ogilvie Jul 07 '20 at 13:37
  • In C you also have flexible arrays. In older C versions this was done usng a `type array[1];` definition and you were supposed to access it out of bounds. The flexible array is cleaner: `type array[];`. – Ted Lyngmo Jul 07 '20 at 13:43
  • You cannot "violate" safety. This violation of language rules is an example of lack of safety in the language. – eerorika Jul 07 '20 at 13:45
  • I'd certainly say it's memory safety. The problem is that even with a check like `i < size ? arr[i] : 0;` you can fool a branch predictor into reading `arr[i]` and placing the memory page in cache, which can then be retrieved faster subsequently. This allows you to effectively read `arr[i]` for arbitrary `i`. Oops. – Bathsheba Jul 07 '20 at 13:47
  • It can be either or both a violation of type safety (caught before execution e.g. diagnosed by the compiler) or of memory safety (caught in execution). Either way, it is an aspect of undefined behaviour in C++. In C++, it is also more complicated because the compiler can be deliberately coerced to not enforce type safety when it otherwise would. The host can be also configured to not enforce memory safety. Incidentally, I have seen problems arise in some ostensibly type safe languages due to edge cases not being diagnosed, but programmers encouraged to complacently believe "no error = safe" – Peter Jul 07 '20 at 13:51
  • The article is rather crappy... you can write perfectly type safe C++ and nowadays even perfectly type safe C. It's kind of like saying "C++ is object-oriented", but you won't get actual OO unless you do such a program design - it's perfectly possible to write non-OO code in C++, just as it is possible to get type safe code. In general, it's quite uninteresting to toss around various terms & labels and try to attach them to this or that language. – Lundin Jul 07 '20 at 14:30
  • For example, an application sending an "out of bounds exception" crashing like a missile through all layers of your application without anyone catching it, is arguably not a safe language. "Hi, I just crashed, but I wanted to let you know that I'm a safe program that doesn't allow out of bounds access. I would rather crash than to see it happen!" Okay, thanks... – Lundin Jul 07 '20 at 14:34
  • *C++ is (morally) a superset of C* Just what in the world does that mean?!?! Language standards have morality?!?! Anything that makes a claim like that is, well, rather lax in its application of logical thought processes and should not be used in interpreting formal standards. It's like a weatherman telling you the weather tomorrow will be ostentatious - it simply doesn't apply. Any evidence that this article wasn't generated by scraping [this website](https://www.makebullshit.com/) over and over? – Andrew Henle Jul 07 '20 at 18:26
  • I may add that C++ is no longer a superset of C. It was, around 1989 -2002. ISO C contains much that doesn't exist in C++ in any form and some that implemented differently. C++ inherits a subset of ANSI C syntax with changes to make it compatible with ISO, but until C99, C11 and C++14 they had differences in underlying ideology. – Swift - Friday Pie Jul 08 '20 at 08:59
  • I’m voting to close this question because it was asked in generalized form , while for concrete platform implementation there is a definite answer,without context question becomes subject to opinion-based debates – Swift - Friday Pie Jul 08 '20 at 09:09

4 Answers4

2

As far as C++ is concerned, neither. Type safety or memory safety are not terms defined in C++ standard.

There is a section on safely derived pointers, which could be related to "memory safety", but it is quite different from the example above.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • 2
    Type and memory safety are general language-agnostic terms. – Eugene Sh. Jul 07 '20 at 13:44
  • 1
    @EugeneSh. but the tag is C++. In other tags, the answer could be different. – SergeyA Jul 07 '20 at 13:45
  • Again, it is language agnostic. It is defined *about* a language, not within the language. – Eugene Sh. Jul 07 '20 at 13:45
  • 1
    C++ doesn't offer any memory safety. For example, if you ran that code in DOS I bet you would have a hard time getting any kind of hard error. This problem is about *lack* of memory safety in the language. If it is a violation of memory safety, that safety is provided by a mechanism outside of the scope of the language. So I believe this answer is correct in that it is neither, as far *"as C++ is concerned"*. But, if there is a hard error, it will be because of a violation of memory safety provided by something else. – François Andrieux Jul 07 '20 at 13:49
  • @FrançoisAndrieux I would agree the it is "neither for C++" if the question was posed "is C++ type or memory safe"? But it is not. It is asking about specific violation, not the general safety. – Eugene Sh. Jul 07 '20 at 13:51
  • 1
    @EugeneSh. The contents of the question and its tags clearly indicate that this question is asking about C or C++. The two quoted paragraphs specifically talk about C and C++. – François Andrieux Jul 07 '20 at 13:55
  • @FrançoisAndrieux My point is not this. My point is that a language can be either memory(type) safe or not. It can't be both. It can't be neither. The specific violation in the question can be related to the language being type unsafe or memory unsafe of something else. This answer implies that it is "something else" which I don't agree with. – Eugene Sh. Jul 07 '20 at 13:58
  • @EugeneSh. other tag could offer a more detailed answer on memory safety. Memory safety is just not a part of C++, so there can be no 'violation of memory safety' in C++. – SergeyA Jul 07 '20 at 13:59
  • @EugeneSh. you are now rephrasing the question to something quite different - you are asking the question "is C++ a memory safe language". It is, of course, not - but this is not the question asked. – SergeyA Jul 07 '20 at 14:00
  • @EugeneSh. I see your point of view now. In that context, yes, the code shows that C++ is not memory safe. That isn't how I interpreted the question, but it seems like a good interpretation. – François Andrieux Jul 07 '20 at 14:00
  • @SergeyA No, I am not. The exact opposite. Please re-read the question. – Eugene Sh. Jul 07 '20 at 14:00
  • @FrançoisAndrieux only I can't find support for this reading of the question in the question text. – SergeyA Jul 07 '20 at 14:00
  • @EugeneSh. the title of the question: "Is accessing an array out of bounds considered a violation of type safety or a violation of memory safety?" In C++ the answer is "neither", it is undefined behavior. – SergeyA Jul 07 '20 at 14:01
  • @SergeyA So here where I do not agree with you. Violation of either of the "safeties" (if it is even a thing - but can't find a better term for this) can (and will) *lead* to UB. But it is not UB by itself. – Eugene Sh. Jul 07 '20 at 14:03
  • @SergeyA I think the problem is that term "violating" in violating a safety is not clearly defined. I now believe OP meant that it prevents the characteristic of that safety from being applied to the language (violating memory safety means is not memory safe). Not that it means that an established safety was defeated (violating memory safety means getting around memory safety). I think looking over the linked article helps understand OP's intention. – François Andrieux Jul 07 '20 at 14:03
  • @EugeneSh. NO! Violation of the "safeties" is impossible in safe languages! This is the core definition of "safety". Java is memory-safe (at least as advertised) and will never allow for any unsafe memory operations. – SergeyA Jul 07 '20 at 14:04
  • @FrançoisAndrieux I think, I agree with you. The question seems to be vague and could be read in multiple different ways. – SergeyA Jul 07 '20 at 14:05
  • @SergeyA This is why there is a note in parentheses. - I do agree that this is not the right terminology. But it is not the point. The op is merely asking - is this thing I did here related to (the lack of) memory safety to type safety. Anyway, I see no point arguing further, my point is made - I believe you are answering the question that was not asked. I did not downvote or something. – Eugene Sh. Jul 07 '20 at 14:08
  • @EugeneSh. Those safeties is subject of platform and implementation. There are safe inplementations of C for example, which is essentially an interpreter written in java (and converts code to java) or in Python. Some hardware platforms can't offer such at all. C and C++ are platform-agnostic which is ortogonal to language-agnostic. – Swift - Friday Pie Jul 08 '20 at 08:54
1

Is the above considered a violation of type safety or a violation of memory safety?

These aren't formal terms. "Type safety" in the scope of the standard is compatible type and compatible type conversion - not really related to array out of bounds.

There is however a formal definition of the term "out-of-bounds store" in the normative Annex L of C17, L.2.1:

out-of-bounds store
an (attempted) access (3.1) that, at run time, for a given computational state, would modify (or, for an object declared volatile, fetch) one or more bytes that lie outside the bounds permitted by this Standard.

Lundin
  • 195,001
  • 40
  • 254
  • 396
1

"Is accessing an array out of bounds considered a violation of type safety or a violation of memory safety?"

First of all, It is considered none of them and even it doesn't really matter if it would be considered to one of them, because it isn't normative. Considerations are subject of one's own opinion and do not reflect constraints in any manner.

IMHO I would say to access memory beyond the bounds of an array when addressing the same has not anything at all to do with type-safety, but that is just my personal opinion.

Fact is that in both languages declare accessing an array out of bounds as undefined behavior and nothing else. They don't classify it either as "memory" nor as "type-safety" violation. Thus to be using such terms to classify it is a matter of one's own opinion and thus not suitable for this site.

In many cases, it will end up in a segmentation fault error at run-time. If it doesn't, you overwrite other important parts of the particular program, other programs or even memory belong to the OS execution - who knows.

Either way, this is clearly indicating that it involves a kind of memory issue and thus could be considered as "memory violation". But this is only non-normative and purely speculative.

So your question seems to be more or less opinion-based and therefore it seems necessary to closing it as "opinion-based" as it literally leads to opinion-based answers:

This question is likely to be answered with opinions rather than facts and citations. It should be updated so it will lead to fact-based answers.

RobertS supports Monica Cellio
  • 14,524
  • 7
  • 33
  • 80
0

Type safety means that the compiler will validate types while compiling, and throw an error if you try to assign the wrong type to a variable. For example:

int x = "foo";

You cannot assign string literal (const char[4]) to type int as they are incompatible.

Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.

~ Memory safety - Wikipedia

Your example, is violation of memory safety, because you are trying to assign a memory, which you have no access to.

Jorengarenar
  • 2,705
  • 5
  • 23
  • 60
  • And I argue it is _also_ a type safety violation because the compiler could see the array is indexed out of bounds but did not warn about it. – Paul Ogilvie Jul 07 '20 at 13:56
  • 2
    Actually `"foo"` is a `const char[4]` type. It being a pointer type is a common misconception. And the program might have access to the memory at `numbers[2]`; it's just that you can't reach it by pointer arithmetic on the first element of `numbers`. – Bathsheba Jul 07 '20 at 14:04
  • @Bathsheba You are tight with type, I've fixed it. With access - yes, program can have access to this memory, but you don't have writing `numbers[2]`. – Jorengarenar Jul 07 '20 at 14:08