Pointers Are Complicated III, or: Pointer-integer casts exposed
In my previous blog post on pointer provenance, I have shown that not thinking carefully about pointers can lead to a compiler that is internally inconsistent: programs that are intended to be well-behaved get miscompiled by a sequence of optimizations, each of which seems intuitively correct in isolation. We thus have to remove or at least restrict at least one of these optimizations. In this pos
The Tower of Weakenings: Memory Models For Everyone - Faultlore
The Tower of Weakenings: Memory Models For Everyone In my previous article I looked at the ways that Rust could be better at pointers. Half of the problems were fundamental issues that affect basically every programming language that lets you mess with pointers directly, and the other half were rust-specific issues. My article also proposed two solutions: for the fundamental issues I proposed “str
Pointers Are Complicated II, or: We need better language specs
Pointers Are Complicated II, or: We need better language specs Some time ago, I wrote a blog post about how there’s more to a pointer than meets the eye. One key point I was trying to make is that just because two pointers point to the same address, does not mean they are equal in the sense that they can be used interchangeably. This “extra information” that distinguishes different pointers to the
Pointers Are Complicated, or: What's in a Byte?
This summer, I am again working on Rust full-time, and again I will work (amongst other things) on a “memory model” for Rust/MIR. However, before I can talk about the ideas I have for this year, I have to finally take the time and dispel the myth that “pointers are simple: they are just integers”. Both parts of this statement are false, at least in languages with unsafe features like Rust or C: Po
Rust lifetimes: Getting away with things that would be reckless in C++ | Random Hacks
Over the years, I’ve learned to be cautious with C++ pointers. In particular, I’m always very careful about who owns a given pointer, and who’s in charge of calling delete on it. But my caution often forces me to write deliberately inefficient functions. For example: vector<string> tokenize_string(const string &text); Here, we have a large string text, and we want to split it into a vector of toke
What is memory safety? - The PL Enthusiast
I am in the process of putting together a MOOC on software security, which goes live in October. At the moment I’m finishing up material on buffer overflows, format string attacks, and other sorts of vulnerabilities in C. After presenting this material, I plan to step back and say, “What do these errors have in common? They are violations of memory safety.” Then I’ll state the definition of memory
Clockwise/Spiral Rule
[This was posted to comp.lang.c by its author, David Anderson, on 1994-05-06.] The ``Clockwise/Spiral Rule'' By David Anderson There is a technique known as the ``Clockwise/Spiral Rule'' which enables any C programmer to parse in their head any C declaration! There are three simple steps to follow: Starting with the unknown element, move in a spiral/clockwise direction; when ecountering the follow
Two star programming
Two star programming 2013-01-08 • C, Torvalds, Algorithms • Comments A few weeks ago Linus Torvalds answered some questions on slashdot. All his responses make good reading but one in particular caught my eye. Asked to describe his favourite kernel hack, Torvalds grumbles he rarely looks at code these days — unless it’s to sort out someone else’s mess. He then pauses to admit he’s proud of the ker
Everything you need to know about pointers in C
Version 1.3.1. Copyright 2005–2023 Peter Hosey. This work is licensed under a Creative Commons Attribution 2.5 License. This document comes with a companion example program, available as one file or as multiple files (zipped). Style used in this document This is regular text. This is a variable, some code, and some sample output. This is a line of code. This is a comment. This is also a comment. T
C++ ポインタ ブートキャンプ
Sapporo.cpp & CLR/H 合同勉強会 ( http://atnd.org/events/33614 ) で発表したスライドです。
Cでのポインタの読み方
Cでのポインタの読み方 Cのポインタの読み方は、ルールを知らないと摩訶不思議です。 ルールを覚えれば、 int (*p[5])[3]; char (*(*fp)(void))(int); なんてのも解読する事ができます。 大事な前程 ポインタを読む際には、「英語で読む」必要があります。 「え～、英語～」 と思う方もいるかもしれませんが、逆に日本語で読む方が大変です。 基本ルール ルール 後置演算子が優先。 関数の() 配列の[] 前置はあとで。 要は、「後ろに何かあったら、後ろが優先」です。 演算子の英語での読み方 * pointer to ... () function returning ... [] array of ... Lesson 1 まず、演算子が単独で出てくる場合です。 Lesson 1-1 pointer to ... int *p; これは、まずpを見ましょう。 i
世界で2番目にわかりやすいポインタの話
これ以上に解りやすく説明できるという人は、@super_rti までURLを教えて下さい。世界一わかりやすいの看板を差し上げます。
プログラム初心者にC言語のポインタを不本意ながら教える羽目になったなら、こう教えると良いよ - 偏見プログラマの語り！
僕がプログラミングに触れた当時は、プログラミングといえば「まず C 言語」でした。それから 10 年以上が経ちました。学校の授業や企業の研修では未だに C 言語を教えているところがあるようです。関数型プログラミング言語という波が来ている 2012 年にもなって未だに C 言語をやっているというのはまるで進歩が無く残念な気もしますが、比較的多くのプログラマに浸透している共通言語を最初に教えるというのは、一方では喜ばしい事だと解釈する事もできるのかもしれません*1。まぁとにかく、本意にせよ不本意にせよ現場で プログラム初心者に C 言語を教える羽目になった 人がたくさんいて、プログラム初心者なのに C 言語を学ばざるを得なくなった 若者がたくさんいるということです。 C 言語を教えるときに避けて通れないのがポインタで、プログラム初心者が C 言語を学ぶときにやたらとつまずく人が多いのがポインタ
ポインタの裏話
ポインタの裏話 岡﨑 直観 okazaki at ecei.tohoku.ac.jp http://www.chokkan.org/ @chokkanorg ポインタの裏話 プログラミング演習Ａ 1 このような説明を 覚えていますか？ 知らなくても全く問題ありません ポインタの裏話 プログラミング演習Ａ 2 int x = 0; &xは変数xの「アドレス」 「番地」「住所」を返す 変数x 0 &x メモリ空間， 記憶空間 変数xのアド レス（住所） ポインタの裏話 プログラミング演習Ａ 3 ＿＿＿_ ／ ＼ 何言ってたんだこいつ？ ／ ⌒ ⌒＼ 番地 アドレス ぬるぽ ／ （●） （●） ＼ ＼ ／ | ､“ ﾞ)（__人__）" ） _＿＿＿＿＿＿＿＿_ ＼ ｡｀ ⌒ﾟ:j´ ,／ jﾞ~~| | | | ＿＿／ ＼ |_＿| | | | || / , ＼ｎ||
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ownership of Memory in C++