WEBVTT

1
00:00:00.120 --> 00:00:04.559
<v Speaker 1>Imagine you were handed the keys to a vehicle, and

2
00:00:05.519 --> 00:00:06.639
<v Speaker 1>not just any vehicle.

3
00:00:06.360 --> 00:00:07.879
<v Speaker 2>Either, right, A serious machine.

4
00:00:07.960 --> 00:00:11.519
<v Speaker 1>Yeah, exactly. We're talking about an absolute masterpiece of engineering,

5
00:00:12.080 --> 00:00:15.519
<v Speaker 1>like a high performance Formula one car. It's capable of

6
00:00:15.599 --> 00:00:22.480
<v Speaker 1>just mind bending speed, unparalleled agility, total responsiveness, total responsiveness. Yeah.

7
00:00:22.519 --> 00:00:25.480
<v Speaker 1>But as you strap into the driver's seat, you notice

8
00:00:25.480 --> 00:00:29.239
<v Speaker 1>something is missing. There are no seat belts, none at all,

9
00:00:29.440 --> 00:00:32.759
<v Speaker 1>no airbags. The traction control has been completely ripped out,

10
00:00:33.320 --> 00:00:36.399
<v Speaker 1>and the steering wheels wired directly to the front axle

11
00:00:36.600 --> 00:00:38.399
<v Speaker 1>without a single ounce of power assist.

12
00:00:38.840 --> 00:00:41.719
<v Speaker 2>It's well, it's a machine built purely for raw performance.

13
00:00:41.840 --> 00:00:45.640
<v Speaker 2>But that means it demands absolute perfection from you, the driver. Right,

14
00:00:45.759 --> 00:00:48.439
<v Speaker 2>like one twitch of your wrist, you know, one millimeter

15
00:00:48.520 --> 00:00:51.200
<v Speaker 2>of overcorrection and you are going straight into the wall

16
00:00:51.200 --> 00:00:52.000
<v Speaker 2>at two hundred.

17
00:00:51.799 --> 00:00:53.880
<v Speaker 1>Miles an hour and the car won't stop you.

18
00:00:53.920 --> 00:00:56.079
<v Speaker 2>No, it assumes you meant to turn into that wall.

19
00:00:56.240 --> 00:00:59.960
<v Speaker 1>That terrifying, exhilarating race car is exactly what we are

20
00:01:00.000 --> 00:01:02.600
<v Speaker 1>exploring today. Welcome to our deep.

21
00:01:02.399 --> 00:01:03.439
<v Speaker 2>Dive, Thanks for having me.

22
00:01:03.759 --> 00:01:07.480
<v Speaker 1>Today. We are looking at the C programming language, utilizing

23
00:01:07.519 --> 00:01:11.599
<v Speaker 1>the comprehensive breakdown found in the second edition of the

24
00:01:11.599 --> 00:01:15.959
<v Speaker 1>textbook C From Theory to Practice by George Stalikas and

25
00:01:16.079 --> 00:01:17.159
<v Speaker 1>Nicolaus Detzelukas.

26
00:01:17.319 --> 00:01:19.280
<v Speaker 2>It's a fantastic resource, it really is.

27
00:01:19.359 --> 00:01:22.040
<v Speaker 1>And our mission for you today is not to just

28
00:01:22.239 --> 00:01:25.319
<v Speaker 1>recite a software manual or like quiz you on semi

29
00:01:25.319 --> 00:01:28.760
<v Speaker 1>Coolin's ut. Whether you are cramming for a computer science

30
00:01:28.799 --> 00:01:32.920
<v Speaker 1>exam or you're just insanely curious about the invisible architecture

31
00:01:32.959 --> 00:01:37.280
<v Speaker 1>of your digital world, we want to extract the hidden gotchaes.

32
00:01:37.000 --> 00:01:38.799
<v Speaker 2>The invisible traps exactly.

33
00:01:38.840 --> 00:01:41.959
<v Speaker 1>We are hunting for those surprising logic traps and foundational

34
00:01:42.040 --> 00:01:44.120
<v Speaker 1>aha moments of C that will fundamentally make you a

35
00:01:44.159 --> 00:01:45.159
<v Speaker 1>sharper thinker.

36
00:01:44.879 --> 00:01:48.200
<v Speaker 2>Because to understand C is to understand the absolute bedrock

37
00:01:48.319 --> 00:01:51.359
<v Speaker 2>of modern computing. I mean, it is a language of incredible,

38
00:01:51.439 --> 00:01:55.000
<v Speaker 2>unmatched power. But as that race car visual suggests, it's

39
00:01:55.760 --> 00:01:57.959
<v Speaker 2>a landscape entirely devoid of safety rails.

40
00:01:58.159 --> 00:02:00.319
<v Speaker 1>So before we start looking under the hood that the

41
00:02:00.319 --> 00:02:04.159
<v Speaker 1>actual code, we should probably figure out why anyone would

42
00:02:04.200 --> 00:02:07.439
<v Speaker 1>build a vehicle with no brakes, Like, why was this

43
00:02:07.560 --> 00:02:11.240
<v Speaker 1>language designed this way? And why decades later is it

44
00:02:11.319 --> 00:02:12.240
<v Speaker 1>still running the world.

45
00:02:12.599 --> 00:02:14.719
<v Speaker 2>Well, the origin story takes us back to the early

46
00:02:14.800 --> 00:02:18.919
<v Speaker 2>nineteen seventies at Bell Labs Okay, Dennis Ritchie alongside a

47
00:02:18.960 --> 00:02:22.680
<v Speaker 2>team of just brilliant engineers. They needed a tool for

48
00:02:22.759 --> 00:02:27.159
<v Speaker 2>a very specific, monumental task. They were rewriting the Unix

49
00:02:27.199 --> 00:02:28.120
<v Speaker 2>operating system.

50
00:02:28.319 --> 00:02:31.439
<v Speaker 1>Wow okay, and at the time, Unix was primarily written

51
00:02:31.479 --> 00:02:32.479
<v Speaker 1>in assembly language.

52
00:02:32.520 --> 00:02:33.039
<v Speaker 2>Exactly.

53
00:02:33.199 --> 00:02:38.039
<v Speaker 1>I've always pictured assembly language as essentially, you know, whispering

54
00:02:38.159 --> 00:02:41.000
<v Speaker 1>raw ones and zeros directly to the computer's processor.

55
00:02:41.120 --> 00:02:42.319
<v Speaker 2>That's practically what it is.

56
00:02:42.439 --> 00:02:45.520
<v Speaker 1>It's incredibly low level, raw machine instructions. That sounds like

57
00:02:45.560 --> 00:02:48.439
<v Speaker 1>a torturous way to write a massive operating system.

58
00:02:48.520 --> 00:02:51.360
<v Speaker 2>Oh, torture is putting it mildly. Programs written in assembly

59
00:02:51.439 --> 00:02:55.520
<v Speaker 2>are notoriously difficult to debug, almost impossible to maintain, and

60
00:02:55.599 --> 00:02:57.360
<v Speaker 2>trying to port them to a different type.

61
00:02:57.159 --> 00:02:58.560
<v Speaker 1>Of computer you'd have to start over.

62
00:02:58.840 --> 00:03:02.039
<v Speaker 2>Yeah, it meant rewriting the whole thing from scratch. So

63
00:03:02.439 --> 00:03:05.639
<v Speaker 2>Richie needed something that would make these tasks manageable, a

64
00:03:05.719 --> 00:03:09.919
<v Speaker 2>language that provided human readable structure but still retained that intimate,

65
00:03:10.120 --> 00:03:14.280
<v Speaker 2>low level control over the computer's physical hardware. He evolved

66
00:03:14.280 --> 00:03:18.919
<v Speaker 2>an earlier language called B and logically enough named the successor.

67
00:03:18.479 --> 00:03:23.560
<v Speaker 1>C pragmatic naming. I love it. But a language created

68
00:03:23.560 --> 00:03:26.680
<v Speaker 1>in a lab doesn't just instantly become the global standard, right.

69
00:03:26.560 --> 00:03:27.479
<v Speaker 2>Oh, not at all.

70
00:03:27.639 --> 00:03:31.840
<v Speaker 1>The text mentions that as C exploded in popularity, different

71
00:03:31.840 --> 00:03:34.639
<v Speaker 1>companies started making their own C compilers to read the code,

72
00:03:35.319 --> 00:03:36.800
<v Speaker 1>and things got pretty chaotic.

73
00:03:37.039 --> 00:03:39.879
<v Speaker 2>Chaos is definitely the right word. In those early years,

74
00:03:40.000 --> 00:03:42.800
<v Speaker 2>programmers relied on a famous book by Brian Kernian and

75
00:03:42.840 --> 00:03:45.439
<v Speaker 2>Dennis Ritchie, the K and R Book, right yep, often

76
00:03:45.520 --> 00:03:47.520
<v Speaker 2>just called the K and R Book. They used it

77
00:03:47.560 --> 00:03:50.800
<v Speaker 2>as their definitive guide. But a textbook isn't a strict

78
00:03:50.800 --> 00:03:53.319
<v Speaker 2>technical standard. It contained ambiguities.

79
00:03:53.400 --> 00:03:54.039
<v Speaker 1>Oh, I see.

80
00:03:54.120 --> 00:03:56.560
<v Speaker 2>You could write a piece of code, feed it into

81
00:03:56.639 --> 00:04:00.879
<v Speaker 2>one company's compiler and get a working program. Feed that

82
00:04:01.000 --> 00:04:04.719
<v Speaker 2>exact same text into a competitor's compiler, and the resulting

83
00:04:04.759 --> 00:04:06.879
<v Speaker 2>program might behave entirely differently.

84
00:04:07.080 --> 00:04:10.280
<v Speaker 1>Wait, so, if this ambiguity was causing so much chaos

85
00:04:10.680 --> 00:04:14.919
<v Speaker 1>when the American National Standards Institute ANSI finally stepped in

86
00:04:14.960 --> 00:04:18.480
<v Speaker 1>to formally standardize the language in nineteen eighty nine, why

87
00:04:18.560 --> 00:04:22.040
<v Speaker 1>didn't they build safety rails into it? That's a great question, Like,

88
00:04:22.240 --> 00:04:24.759
<v Speaker 1>if they are writing the universal rule book, why preserve

89
00:04:24.800 --> 00:04:25.319
<v Speaker 1>the danger?

90
00:04:25.399 --> 00:04:28.399
<v Speaker 2>Well, if we connect this to the bigger picture. Restricting

91
00:04:28.399 --> 00:04:31.839
<v Speaker 2>the language would defeat its entire purpose. The philosophy of

92
00:04:31.879 --> 00:04:36.399
<v Speaker 2>ANSIIC and C in general is built on one core tenant,

93
00:04:36.480 --> 00:04:38.560
<v Speaker 2>which is to trust the programmer implicitly.

94
00:04:38.680 --> 00:04:39.920
<v Speaker 1>Okay, implicitly right.

95
00:04:40.160 --> 00:04:43.519
<v Speaker 2>The language assumes that you, the human typing on the keyboard,

96
00:04:43.639 --> 00:04:45.920
<v Speaker 2>know exactly what you were doing. If you tell the

97
00:04:45.959 --> 00:04:48.560
<v Speaker 2>system to overwrite its own memory, it assumes you have

98
00:04:48.600 --> 00:04:52.040
<v Speaker 2>a brilliant architectural reason for doing so. It won't stop you,

99
00:04:52.240 --> 00:04:53.560
<v Speaker 2>it won't second guess you at all.

100
00:04:53.600 --> 00:04:55.839
<v Speaker 1>We aren't giving you safety rails because you might actually

101
00:04:55.920 --> 00:04:58.079
<v Speaker 1>need to drive on the wall. Okay, I get it.

102
00:04:58.879 --> 00:05:02.800
<v Speaker 1>But if C trusts us implicitly, how do we get

103
00:05:02.839 --> 00:05:06.600
<v Speaker 1>from a text file full of our potentially flawed ideas

104
00:05:07.160 --> 00:05:08.759
<v Speaker 1>to a functioning piece of software.

105
00:05:09.079 --> 00:05:12.160
<v Speaker 2>This requires looking at the C program life cycle, which

106
00:05:12.199 --> 00:05:14.720
<v Speaker 2>is a surprisingly involved four step journey.

107
00:05:14.759 --> 00:05:15.600
<v Speaker 1>Okay, what me through it.

108
00:05:15.680 --> 00:05:18.439
<v Speaker 2>First, you use a text editor to write your source code.

109
00:05:18.560 --> 00:05:22.360
<v Speaker 2>Then a program called the compiler translates that human readable

110
00:05:22.439 --> 00:05:26.639
<v Speaker 2>text into an object file, essentially translating your English like

111
00:05:26.720 --> 00:05:31.319
<v Speaker 2>commands into raw machine language. Next, a critical piece called

112
00:05:31.360 --> 00:05:34.319
<v Speaker 2>the linker takes that object file and connects it with

113
00:05:34.360 --> 00:05:38.319
<v Speaker 2>any standard library functions you use, and finally that produces

114
00:05:38.360 --> 00:05:40.240
<v Speaker 2>the executable file you actually run.

115
00:05:40.480 --> 00:05:42.839
<v Speaker 1>I want to pause on that third step, the linker,

116
00:05:43.040 --> 00:05:45.120
<v Speaker 1>because I think people here compile all the time, but

117
00:05:45.199 --> 00:05:46.800
<v Speaker 1>link gets completely glossed over.

118
00:05:46.920 --> 00:05:47.560
<v Speaker 2>It really does.

119
00:05:47.639 --> 00:05:50.120
<v Speaker 1>What is the linker actually doing In a practical sense.

120
00:05:50.040 --> 00:05:53.639
<v Speaker 2>Think of building a house. Your compiler is the team

121
00:05:53.639 --> 00:05:57.560
<v Speaker 2>that builds the physical structure, the walls, the roof, the pipes,

122
00:05:58.000 --> 00:06:00.560
<v Speaker 2>but those pipes don't have any water in them yet.

123
00:06:00.920 --> 00:06:03.600
<v Speaker 2>The linker is the city worker who comes in and

124
00:06:03.639 --> 00:06:06.360
<v Speaker 2>connects your house's plumbing to the municipal water grid.

125
00:06:06.480 --> 00:06:07.639
<v Speaker 1>Oh that's a great analogy.

126
00:06:07.759 --> 00:06:11.920
<v Speaker 2>Because in C you rarely write every single function from scratch.

127
00:06:12.279 --> 00:06:14.959
<v Speaker 2>You rely on standard libraries for things like printing to

128
00:06:15.000 --> 00:06:18.920
<v Speaker 2>a screen or doing math. The linker stitches your custom

129
00:06:19.000 --> 00:06:23.439
<v Speaker 2>code to those massive pre existing libraries so your program

130
00:06:23.480 --> 00:06:25.160
<v Speaker 2>can actually interact with the computer.

131
00:06:25.480 --> 00:06:28.279
<v Speaker 1>Okay, let's unpack this. That makes perfect sense. But let's

132
00:06:28.279 --> 00:06:30.240
<v Speaker 1>rewind to the compiler, because that's where I think a

133
00:06:30.319 --> 00:06:31.480
<v Speaker 1>dangerous illusion lives.

134
00:06:31.519 --> 00:06:31.720
<v Speaker 2>Oh.

135
00:06:31.759 --> 00:06:36.199
<v Speaker 1>Absolutely, it feels like the compiler is this smart, benevolent

136
00:06:36.360 --> 00:06:40.879
<v Speaker 1>guardian checking your work. Like if the compiler successfully builds

137
00:06:40.920 --> 00:06:44.120
<v Speaker 1>your object file, without throwing any error messages, your program

138
00:06:44.160 --> 00:06:45.199
<v Speaker 1>is good to go. Yeah.

139
00:06:45.199 --> 00:06:48.279
<v Speaker 2>That is the very first grand illusion of C. A

140
00:06:48.319 --> 00:06:51.439
<v Speaker 2>successful compilation simply means your syntax is valid.

141
00:06:51.639 --> 00:06:52.639
<v Speaker 1>Just the syntax, right.

142
00:06:52.879 --> 00:06:54.839
<v Speaker 2>It only checks the grammar of the code. It does

143
00:06:54.959 --> 00:06:57.240
<v Speaker 2>absolutely nothing to verify your logic.

144
00:06:57.439 --> 00:07:01.120
<v Speaker 1>I always compare the compiler to a A six spellchecker

145
00:07:01.160 --> 00:07:04.480
<v Speaker 1>in a word processor. Like the spellchecker confirms you spell

146
00:07:04.519 --> 00:07:08.480
<v Speaker 1>the word UK correctly. The grammar is valid. Yeah, but

147
00:07:08.639 --> 00:07:12.040
<v Speaker 1>it has absolutely no idea. If your sentence meant duck

148
00:07:12.360 --> 00:07:15.639
<v Speaker 1>as in the aquatic bird, or duck as in quickly

149
00:07:15.680 --> 00:07:18.079
<v Speaker 1>lower your head to avoid a flying object.

150
00:07:18.120 --> 00:07:21.279
<v Speaker 2>You're close. But the reality of C is actually a

151
00:07:21.279 --> 00:07:25.079
<v Speaker 2>bit more literal than a spellchecker Husso a modern spellchecker

152
00:07:25.199 --> 00:07:27.519
<v Speaker 2>might look at the context and suggest to fix. The

153
00:07:27.519 --> 00:07:30.040
<v Speaker 2>C compiler doesn't care enough to suggest anything.

154
00:07:30.160 --> 00:07:30.800
<v Speaker 1>Wow, okay.

155
00:07:30.879 --> 00:07:33.600
<v Speaker 2>If you write a program that says print one if

156
00:07:33.680 --> 00:07:36.560
<v Speaker 2>the number is less than five, but you accidentally typed

157
00:07:36.600 --> 00:07:39.199
<v Speaker 2>the greater than symbol, the compiler happily builds it.

158
00:07:39.199 --> 00:07:40.120
<v Speaker 1>It just lets it through.

159
00:07:40.319 --> 00:07:43.839
<v Speaker 2>The syntax is flawless, but the logic is entirely.

160
00:07:43.480 --> 00:07:45.959
<v Speaker 1>Inverted, and that inverted logic is what we call a

161
00:07:45.959 --> 00:07:50.319
<v Speaker 1>bug which has a fantastic literal origin story involving Grace Hopper.

162
00:07:50.399 --> 00:07:53.480
<v Speaker 2>Right, Yes, the pioneering computer scientist. She and her team

163
00:07:53.480 --> 00:07:56.720
<v Speaker 2>were investigating a hardware malfunction in an early electro mechanical

164
00:07:56.720 --> 00:08:00.720
<v Speaker 2>computer and found a literal physical moth trapped inside.

165
00:08:00.360 --> 00:08:01.560
<v Speaker 1>A relay, a real bug.

166
00:08:01.759 --> 00:08:04.680
<v Speaker 2>Yeah. They taped the moth into the log book, noting

167
00:08:04.720 --> 00:08:06.639
<v Speaker 2>they had literally debugged the machine.

168
00:08:06.879 --> 00:08:10.959
<v Speaker 1>That's amazing. Yeah, But in c our bugs are invisible.

169
00:08:11.040 --> 00:08:16.040
<v Speaker 1>They're entirely conceptual. Sometimes the language's own syntax rules create

170
00:08:16.079 --> 00:08:20.000
<v Speaker 1>traps that hide these bugs from the compiler. Yes, let's

171
00:08:20.040 --> 00:08:21.199
<v Speaker 1>look at the nest to comment trap.

172
00:08:21.319 --> 00:08:24.439
<v Speaker 2>Oh, this is a classic. So comments are notes you

173
00:08:24.519 --> 00:08:27.319
<v Speaker 2>leave for yourself in the code. You're telling the compiler

174
00:08:27.399 --> 00:08:28.360
<v Speaker 2>ignore everything here.

175
00:08:28.560 --> 00:08:28.759
<v Speaker 1>Right.

176
00:08:29.120 --> 00:08:31.519
<v Speaker 2>In C, you start a comment block with a forward

177
00:08:31.560 --> 00:08:33.840
<v Speaker 2>slash and an asterisk, and you end it with an

178
00:08:33.879 --> 00:08:35.200
<v Speaker 2>asterisk and a forward slash.

179
00:08:35.320 --> 00:08:37.360
<v Speaker 1>See's fool proof. I tell it to stop reading, and

180
00:08:37.360 --> 00:08:38.759
<v Speaker 1>then I tell it to start reading again.

181
00:08:38.879 --> 00:08:40.879
<v Speaker 2>The trap springs when you try to put a comment

182
00:08:40.960 --> 00:08:44.320
<v Speaker 2>inside another comment, nesting them. The strict rule of the

183
00:08:44.320 --> 00:08:47.440
<v Speaker 2>C compiler is that a comment ends the absolute moment

184
00:08:47.480 --> 00:08:50.440
<v Speaker 2>it sees the very first closing asterisk slash.

185
00:08:50.480 --> 00:08:50.759
<v Speaker 1>Wait.

186
00:08:50.840 --> 00:08:53.759
<v Speaker 2>Really, yes, it doesn't keep count of how many times

187
00:08:53.759 --> 00:08:54.840
<v Speaker 2>you open a comment block.

188
00:08:55.000 --> 00:08:58.440
<v Speaker 1>Uh okay. So if I have fifty lines of code

189
00:08:58.440 --> 00:09:01.000
<v Speaker 1>that I want to temporarily disable, so I wrapped the

190
00:09:01.000 --> 00:09:03.919
<v Speaker 1>whole giant block in comment symbols, but deep inside that

191
00:09:03.960 --> 00:09:07.440
<v Speaker 1>block online twenty, I had previously written a tiny little

192
00:09:07.480 --> 00:09:10.200
<v Speaker 1>note to myself with its own comment symbols.

193
00:09:10.360 --> 00:09:13.840
<v Speaker 2>The compiler hits that tiny note's closing symbol online twenty,

194
00:09:14.200 --> 00:09:18.639
<v Speaker 2>declares the massive comment block finished, and immediately begins executing

195
00:09:18.679 --> 00:09:22.159
<v Speaker 2>lines twenty one through fifty as live, active code.

196
00:09:22.240 --> 00:09:24.919
<v Speaker 1>Oh wow, And if lines twenty one through fifty happen

197
00:09:25.000 --> 00:09:29.159
<v Speaker 1>to be grammatically valid syntax, the compiler won't complain at all,

198
00:09:29.320 --> 00:09:31.519
<v Speaker 1>not a peep. It will just build a completely different,

199
00:09:31.559 --> 00:09:33.399
<v Speaker 1>deeply flawed program exactly.

200
00:09:33.480 --> 00:09:35.679
<v Speaker 2>It assumes you wanted those lines to be active.

201
00:09:36.000 --> 00:09:40.120
<v Speaker 1>Terrifying. So if syntax itself is full of invisible logic traps,

202
00:09:40.559 --> 00:09:43.720
<v Speaker 1>what happens when we successfully compile the code and start

203
00:09:43.759 --> 00:09:45.080
<v Speaker 1>dealing with the computer's memory.

204
00:09:45.279 --> 00:09:48.840
<v Speaker 2>Well, this is where human intuition violently collides with machine reality.

205
00:09:49.200 --> 00:09:52.519
<v Speaker 2>Variables in C are at their core just names for

206
00:09:52.600 --> 00:09:55.919
<v Speaker 2>specific one byte memory cells. In your computer's ramky, you

207
00:09:55.960 --> 00:09:58.799
<v Speaker 2>are just assigning a human readable label to a physical

208
00:09:58.840 --> 00:10:00.720
<v Speaker 2>address in the hardware, and the type.

209
00:10:00.480 --> 00:10:02.840
<v Speaker 1>Of variable you declare, like an integer or a decimal,

210
00:10:03.000 --> 00:10:05.360
<v Speaker 1>tells a computer how much physical memory to grab and

211
00:10:05.399 --> 00:10:07.360
<v Speaker 1>how to interpret the ones and zeros inside it.

212
00:10:07.639 --> 00:10:10.639
<v Speaker 2>Right, Let's test your intuition on how that memory is interpreted.

213
00:10:11.000 --> 00:10:13.120
<v Speaker 2>Suppose you declare a floating point.

214
00:10:12.879 --> 00:10:14.679
<v Speaker 1>Variable a number with a decimal.

215
00:10:14.759 --> 00:10:18.120
<v Speaker 2>Yeah, exactly, You write float a equals three point one.

216
00:10:18.399 --> 00:10:20.440
<v Speaker 1>Done. I have a box labeled A, and I've put

217
00:10:20.480 --> 00:10:21.600
<v Speaker 1>three point one inside it.

218
00:10:21.720 --> 00:10:24.159
<v Speaker 2>Okay. Later in your code, you write an if statement.

219
00:10:24.279 --> 00:10:27.240
<v Speaker 2>You ask the program if A equals three point one?

220
00:10:27.279 --> 00:10:28.720
<v Speaker 2>Does it equal three point one?

221
00:10:28.759 --> 00:10:30.320
<v Speaker 1>Well, I just put three point one in the box,

222
00:10:30.399 --> 00:10:33.039
<v Speaker 1>so obviously yes it's true, and c.

223
00:10:33.360 --> 00:10:35.519
<v Speaker 2>That statement will shockingly return false.

224
00:10:35.879 --> 00:10:38.679
<v Speaker 1>Wait, what if I definitively set it variable to three

225
00:10:38.679 --> 00:10:41.399
<v Speaker 1>point one? How can the computer possibly look at it

226
00:10:41.440 --> 00:10:43.720
<v Speaker 1>a microsecond later and tell me it's not three point.

227
00:10:43.559 --> 00:10:46.600
<v Speaker 2>One because of the translation between our base ten decimal

228
00:10:46.639 --> 00:10:50.080
<v Speaker 2>system and the computer's base two binary system. Think about

229
00:10:50.080 --> 00:10:52.480
<v Speaker 2>how we represent the fraction one third in decimals.

230
00:10:52.519 --> 00:10:54.360
<v Speaker 1>It's an endless point three to three three.

231
00:10:54.360 --> 00:10:56.600
<v Speaker 2>Three, right, you can never write it perfectly. The exact

232
00:10:56.639 --> 00:10:59.120
<v Speaker 2>same thing happens to computers with certain decimals like three

233
00:10:59.159 --> 00:11:02.399
<v Speaker 2>point one. Binary cannot represent three point one perfectly, so

234
00:11:02.480 --> 00:11:05.879
<v Speaker 2>the machine stores a value that is incredibly microscopically close

235
00:11:05.919 --> 00:11:06.840
<v Speaker 2>to three point one.

236
00:11:06.679 --> 00:11:09.399
<v Speaker 1>Like three point one zero zero zero zero zero zero

237
00:11:09.480 --> 00:11:11.080
<v Speaker 1>zero zero zero zero zero one.

238
00:11:11.320 --> 00:11:14.679
<v Speaker 2>Yes, So when you ask the compiler if aqua equals

239
00:11:14.720 --> 00:11:17.919
<v Speaker 2>three point one, the machine compares the literal perfect three

240
00:11:17.919 --> 00:11:22.320
<v Speaker 2>point one. You just type against the slightly imprecise representations stored.

241
00:11:22.120 --> 00:11:23.440
<v Speaker 1>In memory, and they don't match.

242
00:11:23.480 --> 00:11:26.679
<v Speaker 2>They don't perfectly match, So if strict equality fails, you

243
00:11:26.720 --> 00:11:29.360
<v Speaker 2>should almost never use the double equal sign to compare

244
00:11:29.399 --> 00:11:31.720
<v Speaker 2>floating point numbers. You always have to check if the

245
00:11:31.759 --> 00:11:34.799
<v Speaker 2>difference between them is smaller than a tiny acceptable margin.

246
00:11:35.120 --> 00:11:39.559
<v Speaker 1>Here's where it gets really interesting, because it's completely rational

247
00:11:39.559 --> 00:11:43.559
<v Speaker 1>from the machine's perspective, but deeply unintuitive for a human.

248
00:11:43.679 --> 00:11:45.799
<v Speaker 1>But I know it gets stranger. Hit me with the

249
00:11:45.879 --> 00:11:47.679
<v Speaker 1>sign versus unsigned trap.

250
00:11:47.879 --> 00:11:50.879
<v Speaker 2>Let's test your intuition again. We declare a sign into JERM,

251
00:11:50.960 --> 00:11:53.039
<v Speaker 2>meaning it can be negative or positive. We set it

252
00:11:53.039 --> 00:11:56.240
<v Speaker 2>to negative twenty. Then we declare an unsigned into JERM,

253
00:11:56.320 --> 00:11:58.879
<v Speaker 2>meaning it can only ever be positive. We set it

254
00:11:58.919 --> 00:11:59.879
<v Speaker 2>to two hundred.

255
00:12:00.240 --> 00:12:02.360
<v Speaker 1>Negative twenty positive two hundred. Got it.

256
00:12:02.519 --> 00:12:04.960
<v Speaker 2>Now we write a simple condition is negative twenty less

257
00:12:04.960 --> 00:12:06.080
<v Speaker 2>than two hundred, which one is.

258
00:12:06.080 --> 00:12:09.240
<v Speaker 1>Smaller in any universe. Negative twenty is a vastly smaller

259
00:12:09.320 --> 00:12:10.840
<v Speaker 1>number than positive two hundred.

260
00:12:11.080 --> 00:12:14.679
<v Speaker 2>In C. If you compare those two specific variables, the

261
00:12:14.799 --> 00:12:18.559
<v Speaker 2>compiler evaluates that statement is false. Negative twenty is not

262
00:12:18.679 --> 00:12:19.639
<v Speaker 2>less than two hundred.

263
00:12:20.159 --> 00:12:22.960
<v Speaker 1>That feels broken. What on earth is the machine doing

264
00:12:23.000 --> 00:12:24.799
<v Speaker 1>behind the scenes to reach that conclusion.

265
00:12:25.000 --> 00:12:28.799
<v Speaker 2>What's fascinating here is that it's applying implicit arithmetic conversions.

266
00:12:29.519 --> 00:12:32.519
<v Speaker 2>C has very strict rules for mixing different data types

267
00:12:32.559 --> 00:12:35.440
<v Speaker 2>in an equation. When you force a comparison between a

268
00:12:35.480 --> 00:12:39.879
<v Speaker 2>signed integer and an unsigned integer, the compiler silently promotes

269
00:12:39.919 --> 00:12:42.399
<v Speaker 2>the sign integer to match the unsigned one.

270
00:12:42.440 --> 00:12:44.360
<v Speaker 1>So it takes my negative twenty and just strips the

271
00:12:44.360 --> 00:12:46.279
<v Speaker 1>minus sign off. It becomes a positive twenty.

272
00:12:46.360 --> 00:12:48.559
<v Speaker 2>It's much weirder than that. It doesn't strip the sign

273
00:12:48.679 --> 00:12:52.480
<v Speaker 2>it changes how it reads the underlying binary code. Computers

274
00:12:52.480 --> 00:12:55.639
<v Speaker 2>store negative numbers using a system called two's compliment.

275
00:12:55.720 --> 00:12:57.120
<v Speaker 1>Two's compliment, okay, think.

276
00:12:56.960 --> 00:12:59.159
<v Speaker 2>Of the leftmost bit in the binary sequence like a

277
00:12:59.159 --> 00:13:02.240
<v Speaker 2>toggle switch in a sign number. If that leftmost switch

278
00:13:02.279 --> 00:13:04.279
<v Speaker 2>is flipped on, the computer reads that as the rule

279
00:13:04.600 --> 00:13:06.320
<v Speaker 2>this entire number is negative.

280
00:13:06.440 --> 00:13:08.879
<v Speaker 1>Okay, the switch tells the system how to behave.

281
00:13:09.159 --> 00:13:12.639
<v Speaker 2>But when the compiler promotes that number to unsigned, it

282
00:13:12.720 --> 00:13:15.759
<v Speaker 2>suddenly forgets the negative rule. It looks at that exact

283
00:13:15.840 --> 00:13:19.320
<v Speaker 2>same leftmost switch being flipped on, but because unsigned numbers

284
00:13:19.320 --> 00:13:22.960
<v Speaker 2>can't be negative, it interprets that switch simply as a

285
00:13:23.039 --> 00:13:24.639
<v Speaker 2>massive numeric value.

286
00:13:24.759 --> 00:13:27.240
<v Speaker 1>Wait, so what happens to my negative twenty when that

287
00:13:27.320 --> 00:13:31.279
<v Speaker 1>leftmost bit gets misread as a giant positive value.

288
00:13:30.879 --> 00:13:33.399
<v Speaker 2>In a typical thirty two bit system, that negative twenty

289
00:13:33.440 --> 00:13:36.639
<v Speaker 2>suddenly transforms into a positive number right around four point

290
00:13:36.679 --> 00:13:37.320
<v Speaker 2>two billion.

291
00:13:37.399 --> 00:13:38.519
<v Speaker 1>Four point two billion.

292
00:13:38.720 --> 00:13:41.519
<v Speaker 2>Yes, so the machine is actually evaluating the statement is

293
00:13:41.600 --> 00:13:45.120
<v Speaker 2>four point two billion less than two hundred and naturally

294
00:13:45.320 --> 00:13:47.320
<v Speaker 2>mathematically it answers false.

295
00:13:47.480 --> 00:13:49.799
<v Speaker 1>It's doing exactly what we told it to do, even

296
00:13:49.840 --> 00:13:54.039
<v Speaker 1>if what we told it to do results in absolute lunacy. Precisely, so,

297
00:13:54.080 --> 00:13:57.000
<v Speaker 1>if memory itself is this fragile, what happens when lets

298
00:13:57.000 --> 00:13:59.600
<v Speaker 1>a more predictable human touch it, Like when a user

299
00:13:59.639 --> 00:14:03.000
<v Speaker 1>actually types something into the program using our input and

300
00:14:03.000 --> 00:14:04.679
<v Speaker 1>output functions, dealing.

301
00:14:04.360 --> 00:14:08.399
<v Speaker 2>With the outside world introduces entirely new vulnerabilities. The standard

302
00:14:08.399 --> 00:14:10.639
<v Speaker 2>C library gives us print for outputting text to the

303
00:14:10.679 --> 00:14:13.519
<v Speaker 2>screen and scam for taking input from the keyboard.

304
00:14:13.679 --> 00:14:17.120
<v Speaker 1>Printsif seems mostly harmless, though you can use scape sequences

305
00:14:17.159 --> 00:14:20.240
<v Speaker 1>to format text in weird ways. I was fascinated by

306
00:14:20.240 --> 00:14:21.679
<v Speaker 1>the carriage return sequence.

307
00:14:21.720 --> 00:14:24.360
<v Speaker 2>The backslash R no backslash R is a relic from

308
00:14:24.399 --> 00:14:27.480
<v Speaker 2>the typewriter days. It moves the invisible cursor back to

309
00:14:27.519 --> 00:14:30.679
<v Speaker 2>the absolute beginning of the current line, but critically it

310
00:14:30.720 --> 00:14:32.159
<v Speaker 2>does not move down to a new line.

311
00:14:32.240 --> 00:14:35.960
<v Speaker 1>Selekas and Silekas highlight a brilliant example of this. If

312
00:14:36.000 --> 00:14:39.080
<v Speaker 1>you tell print to print the word sample, then issue

313
00:14:39.080 --> 00:14:41.879
<v Speaker 1>the carriage return, and then print the word text, the

314
00:14:41.919 --> 00:14:44.360
<v Speaker 1>output on your screen isn't sample text.

315
00:14:44.519 --> 00:14:45.080
<v Speaker 2>No, it's not.

316
00:14:45.320 --> 00:14:48.279
<v Speaker 1>The output is the bizarre word text all because.

317
00:14:48.080 --> 00:14:53.039
<v Speaker 2>The machine prints sampl e. Then the carriage return snaps

318
00:14:53.080 --> 00:14:55.919
<v Speaker 2>the cursor back to hover over the S. Then it

319
00:14:55.960 --> 00:15:00.159
<v Speaker 2>twints text right over the top of the first four letters, overwriting.

320
00:14:59.639 --> 00:15:01.960
<v Speaker 1>Them writing the samps yes.

321
00:15:02.039 --> 00:15:04.000
<v Speaker 2>But it leaves the L and E sitting at the

322
00:15:04.120 --> 00:15:05.960
<v Speaker 2>end untouched textle.

323
00:15:05.720 --> 00:15:10.080
<v Speaker 1>Again malicious compliance, but printing text is relatively safe. Taking

324
00:15:10.200 --> 00:15:13.200
<v Speaker 1>user input is where the real danger lies. The scant function.

325
00:15:13.480 --> 00:15:15.879
<v Speaker 1>When I first tried to learn C, SCAMF was the

326
00:15:15.919 --> 00:15:18.679
<v Speaker 1>source of so many instant, mysterious program crashes.

327
00:15:19.120 --> 00:15:23.600
<v Speaker 2>It is arguably the most famous trap for novices. When

328
00:15:23.639 --> 00:15:26.120
<v Speaker 2>you use stamp to read a number from the keyboard

329
00:15:26.200 --> 00:15:28.759
<v Speaker 2>and store it in a variable, you must put an

330
00:15:28.799 --> 00:15:32.039
<v Speaker 2>ampersand the and symbol in front of the variable name

331
00:15:32.080 --> 00:15:32.879
<v Speaker 2>in your code.

332
00:15:33.240 --> 00:15:35.639
<v Speaker 1>So if my variable is named score, I can't just

333
00:15:35.720 --> 00:15:37.720
<v Speaker 1>write scamf and point it at score. I have to

334
00:15:37.720 --> 00:15:41.200
<v Speaker 1>write ampersand score exactly. If I forget that one tiny

335
00:15:41.200 --> 00:15:45.080
<v Speaker 1>little symbol, the whole program explodes. Why is SCAMF so

336
00:15:45.240 --> 00:15:49.000
<v Speaker 1>incredibly needy about the Ampersand when print chef doesn't require

337
00:15:49.000 --> 00:15:49.519
<v Speaker 1>it at all?

338
00:15:49.840 --> 00:15:52.679
<v Speaker 2>It goes back to our definition of variables as physical

339
00:15:52.720 --> 00:15:55.639
<v Speaker 2>memory addresses. When you use print, the function just needs

340
00:15:55.679 --> 00:15:57.879
<v Speaker 2>to look at the value currently stored in the variable

341
00:15:57.960 --> 00:15:59.000
<v Speaker 2>so it can display it.

342
00:15:59.000 --> 00:16:01.200
<v Speaker 1>It's like me handing you a photocopy of a document.

343
00:16:01.679 --> 00:16:03.279
<v Speaker 1>You can read it, you could show it to people,

344
00:16:03.399 --> 00:16:05.720
<v Speaker 1>but you aren't changing the original document sitting in my

345
00:16:05.759 --> 00:16:06.919
<v Speaker 1>filing cabinet exactly.

346
00:16:06.960 --> 00:16:10.600
<v Speaker 2>It's read only access. But SCAMF has a much more

347
00:16:10.639 --> 00:16:14.039
<v Speaker 2>invasive job Its entire purpose is to take new data

348
00:16:14.080 --> 00:16:17.120
<v Speaker 2>from the keyboard and save it into your variable. To

349
00:16:17.200 --> 00:16:19.879
<v Speaker 2>do that, it can't just look at a photocopy. It

350
00:16:19.960 --> 00:16:23.240
<v Speaker 2>needs to know the exact physical memory location in the

351
00:16:23.240 --> 00:16:26.279
<v Speaker 2>computer's RAM so it can go there and overwrite whatever

352
00:16:26.360 --> 00:16:27.440
<v Speaker 2>is currently in that cell.

353
00:16:27.679 --> 00:16:30.840
<v Speaker 1>So adding that ampersand is like handing scamp. The physical

354
00:16:30.879 --> 00:16:32.919
<v Speaker 1>GPS coordinates to the memory cell.

355
00:16:33.080 --> 00:16:37.159
<v Speaker 2>Yes, the ampersand is the address of operator. If you

356
00:16:37.200 --> 00:16:40.000
<v Speaker 2>forget it, SCAMF takes the current value of your variable.

357
00:16:40.080 --> 00:16:42.320
<v Speaker 2>Let's say the variable holds the number ten and assumes

358
00:16:42.320 --> 00:16:43.919
<v Speaker 2>that ten is the memory address.

359
00:16:44.240 --> 00:16:44.759
<v Speaker 1>Oh no.

360
00:16:45.080 --> 00:16:47.960
<v Speaker 2>It then takes the user's keyboard input and tries to

361
00:16:48.000 --> 00:16:52.279
<v Speaker 2>aggressively shove it into memory location ten. Memory location ten

362
00:16:52.320 --> 00:16:55.759
<v Speaker 2>almost certainly belongs to the operating system's core functions, and.

363
00:16:55.679 --> 00:16:58.559
<v Speaker 1>The operating system detects a rogue program trying to override

364
00:16:58.559 --> 00:17:02.320
<v Speaker 1>its brain and instill shuts you down a segmentation faull

365
00:17:02.840 --> 00:17:04.920
<v Speaker 1>all because of one missing amper.

366
00:17:04.599 --> 00:17:08.160
<v Speaker 2>Sand And remember, the compiler won't warn you. The compiler

367
00:17:08.240 --> 00:17:12.039
<v Speaker 2>sees STAMP pointing to a value, assumes you genuinely intended

368
00:17:12.039 --> 00:17:14.559
<v Speaker 2>to use that value as a raw memory address, and

369
00:17:14.640 --> 00:17:17.240
<v Speaker 2>compiles the time bomb directly into your software.

370
00:17:17.359 --> 00:17:19.640
<v Speaker 1>There is another SCAMF trap mentioned in the material that

371
00:17:19.720 --> 00:17:23.240
<v Speaker 1>doesn't crash the program, but effectively freezes it in time.

372
00:17:23.240 --> 00:17:27.359
<v Speaker 2>The hanging prompt trap. A lot of programmers intuitively add

373
00:17:27.400 --> 00:17:30.720
<v Speaker 2>a new line character a backslash end to the end

374
00:17:30.799 --> 00:17:33.480
<v Speaker 2>of their scam formatting string right they think it will

375
00:17:33.519 --> 00:17:36.079
<v Speaker 2>neatly move the cursor to the next line after the

376
00:17:36.160 --> 00:17:37.519
<v Speaker 2>user hits the enter key.

377
00:17:37.480 --> 00:17:40.480
<v Speaker 1>Because it's exactly what backslash end does in print. It's

378
00:17:40.559 --> 00:17:41.039
<v Speaker 1>just a habit.

379
00:17:41.319 --> 00:17:44.759
<v Speaker 2>But in SCAMF backslash end doesn't mean print a new line.

380
00:17:44.799 --> 00:17:47.400
<v Speaker 2>It tells the function to read and discard all white

381
00:17:47.400 --> 00:17:50.960
<v Speaker 2>space characters until it finds a physical, non white space character.

382
00:17:51.160 --> 00:17:54.880
<v Speaker 1>So the user types their number, hits enter, and uh,

383
00:17:55.240 --> 00:17:56.039
<v Speaker 1>nothing happens.

384
00:17:56.119 --> 00:17:58.720
<v Speaker 2>The program just sits there, completely frozen. You can hit

385
00:17:58.759 --> 00:18:01.720
<v Speaker 2>the enter key one thousand times. You are just generating

386
00:18:01.759 --> 00:18:05.759
<v Speaker 2>white space, which Stamp happily consumes in discards, waiting endlessly

387
00:18:05.839 --> 00:18:07.799
<v Speaker 2>until you type a letter or a number and press

388
00:18:07.920 --> 00:18:09.240
<v Speaker 2>enter again to break the loop.

389
00:18:09.480 --> 00:18:12.839
<v Speaker 1>So we've successfully stored our data, survived the memory traps,

390
00:18:13.079 --> 00:18:16.359
<v Speaker 1>and navigated the io mindfield without causing a segmentation fault,

391
00:18:16.519 --> 00:18:20.440
<v Speaker 1>barely barely. Yeah. Our final frontier of invisible traps lies

392
00:18:20.480 --> 00:18:22.839
<v Speaker 1>in how we manipulate that data mathematically.

393
00:18:23.160 --> 00:18:26.759
<v Speaker 2>C is legendary for its operator quirks, and perhaps the

394
00:18:26.759 --> 00:18:30.119
<v Speaker 2>most common mathematical error in all of programming is confusing

395
00:18:30.119 --> 00:18:33.160
<v Speaker 2>the assignment operator with the equality operator.

396
00:18:32.720 --> 00:18:35.079
<v Speaker 1>The single equals sign versus the double equal sign.

397
00:18:35.119 --> 00:18:38.880
<v Speaker 2>A single equals sign assigns of value A equals ten,

398
00:18:39.200 --> 00:18:42.119
<v Speaker 2>takes the number ten and puts it into the variable A.

399
00:18:42.119 --> 00:18:45.400
<v Speaker 2>A double equal sign compares two values. Okay, A double

400
00:18:45.440 --> 00:18:50.000
<v Speaker 2>equals ten. Asks the mathematical question, is the value currently

401
00:18:50.079 --> 00:18:52.519
<v Speaker 2>inside A exactly equal to ten?

402
00:18:52.680 --> 00:18:54.680
<v Speaker 1>So what happens if I am writing an if statement

403
00:18:54.720 --> 00:18:56.519
<v Speaker 1>try and ask a question? But I make a typo

404
00:18:57.079 --> 00:18:59.720
<v Speaker 1>instead of asking if a double equals ten, I accidentally

405
00:18:59.720 --> 00:19:02.880
<v Speaker 1>type if A equals ten with a single equal sign.

406
00:19:03.160 --> 00:19:06.359
<v Speaker 2>C will execute it perfectly. First, it evaluates the single

407
00:19:06.359 --> 00:19:09.200
<v Speaker 2>equal sign. It forcefully takes the number ten and assigns

408
00:19:09.240 --> 00:19:12.119
<v Speaker 2>it to the variable A, instantly destroying whatever data was

409
00:19:12.160 --> 00:19:12.920
<v Speaker 2>in A previously.

410
00:19:13.000 --> 00:19:13.559
<v Speaker 1>Oh wow.

411
00:19:13.640 --> 00:19:16.000
<v Speaker 2>Then it evaluates the result of that assignment to decide

412
00:19:16.000 --> 00:19:18.319
<v Speaker 2>if the if statement is true or false. In C,

413
00:19:18.799 --> 00:19:22.000
<v Speaker 2>any non zero value is considered true. Since ten is

414
00:19:22.000 --> 00:19:25.160
<v Speaker 2>not zero. The statement evaluates is true every single time.

415
00:19:25.440 --> 00:19:27.200
<v Speaker 1>Let me make sure I understand the gravity of that.

416
00:19:27.880 --> 00:19:32.480
<v Speaker 1>By missing one single keystroke, I have silently corrupted my

417
00:19:32.599 --> 00:19:36.359
<v Speaker 1>own data by overwriting my variable, and I have forced

418
00:19:36.400 --> 00:19:41.039
<v Speaker 1>a conditional branch of my program to always execute, regardless

419
00:19:41.039 --> 00:19:43.400
<v Speaker 1>of what the user actually did. Yep, and the compiler

420
00:19:43.559 --> 00:19:46.039
<v Speaker 1>just nods and says, looks good to me.

421
00:19:46.279 --> 00:19:49.480
<v Speaker 2>It assumes you are a genius who intended to perform

422
00:19:49.519 --> 00:19:52.640
<v Speaker 2>an assignment and an evaluation in the exact same.

423
00:19:52.480 --> 00:19:56.000
<v Speaker 1>Breath, which brings up the increment operators, the prefix and postfix.

424
00:19:56.000 --> 00:19:58.039
<v Speaker 1>This is another area where doing two things at once

425
00:19:58.559 --> 00:20:00.440
<v Speaker 1>creates a massive chronological trap.

426
00:20:00.519 --> 00:20:03.720
<v Speaker 2>You can increase a variable's value by exactly one by

427
00:20:03.759 --> 00:20:06.000
<v Speaker 2>typing two plus signs. If you put them before the

428
00:20:06.079 --> 00:20:08.799
<v Speaker 2>variable name, like plus plus a, it's called prefix. You

429
00:20:08.839 --> 00:20:11.119
<v Speaker 2>put them after like A plus plus, it's postfix.

430
00:20:11.200 --> 00:20:11.519
<v Speaker 1>Okay.

431
00:20:11.559 --> 00:20:13.599
<v Speaker 2>If they're just sitting on a line entirely by themselves,

432
00:20:13.680 --> 00:20:15.880
<v Speaker 2>they do the exact same thing. All goes up by one,

433
00:20:15.960 --> 00:20:16.240
<v Speaker 2>But the.

434
00:20:16.160 --> 00:20:19.599
<v Speaker 1>Trap springs when you use them inside a larger mathematical equation. Right,

435
00:20:20.400 --> 00:20:24.599
<v Speaker 1>the placement of those plus signs changes the actual timeline

436
00:20:24.640 --> 00:20:25.160
<v Speaker 1>of events.

437
00:20:25.440 --> 00:20:29.240
<v Speaker 2>Consider the equation B equals plus plus A. The prefix

438
00:20:29.319 --> 00:20:33.279
<v Speaker 2>means C increments the value of A before it evaluates

439
00:20:33.319 --> 00:20:35.519
<v Speaker 2>the rest of the equation. If A started as four,

440
00:20:35.640 --> 00:20:39.559
<v Speaker 2>it immediately becomes five, then that new value five is

441
00:20:39.599 --> 00:20:42.480
<v Speaker 2>assigned to B. Both variables end up holding five.

442
00:20:42.759 --> 00:20:45.920
<v Speaker 1>But if I use postfix, B equals A plus.

443
00:20:45.759 --> 00:20:49.000
<v Speaker 2>Plus postfix means C uses the current value of A

444
00:20:49.039 --> 00:20:52.359
<v Speaker 2>first and only increments it after the assignment is complete.

445
00:20:52.519 --> 00:20:54.920
<v Speaker 2>If a's four, it takes that four and assigns it

446
00:20:54.960 --> 00:20:57.279
<v Speaker 2>to B. The equation is over, and then then in

447
00:20:57.319 --> 00:20:59.759
<v Speaker 2>the background, it increments A to five. So B is

448
00:20:59.759 --> 00:21:02.519
<v Speaker 2>whole old data four while A has moved onto five.

449
00:21:02.599 --> 00:21:04.559
<v Speaker 1>Depending on which side of the letter you type, the

450
00:21:04.599 --> 00:21:07.640
<v Speaker 1>plus signs your entire program is either working with current

451
00:21:07.720 --> 00:21:11.119
<v Speaker 1>data or stale data. Exact, which actually segues beautifully into

452
00:21:11.119 --> 00:21:16.119
<v Speaker 1>our final and maybe most insidious chronological trap logical short circuiting. OH.

453
00:21:16.200 --> 00:21:18.759
<v Speaker 2>This raises an important question about side effects and code.

454
00:21:19.039 --> 00:21:21.200
<v Speaker 2>This involves the logical A and D operator, which is

455
00:21:21.240 --> 00:21:24.240
<v Speaker 2>two ampersands, and the logical R operator, which is two

456
00:21:24.240 --> 00:21:25.000
<v Speaker 2>pipe symbols.

457
00:21:25.319 --> 00:21:28.079
<v Speaker 1>Let's focus on the A and D operator. I want

458
00:21:28.079 --> 00:21:29.599
<v Speaker 1>to try an analogy here to see if I have the

459
00:21:29.640 --> 00:21:34.039
<v Speaker 1>mechanics right. Imagine a lazy bouncer working the door at

460
00:21:34.039 --> 00:21:35.200
<v Speaker 1>an exclusive nightclub.

461
00:21:35.480 --> 00:21:36.319
<v Speaker 2>Okay, I like it.

462
00:21:36.759 --> 00:21:39.160
<v Speaker 1>The rule to get in is strict. You must be

463
00:21:39.200 --> 00:21:41.440
<v Speaker 1>twenty one A and D you must be on the

464
00:21:41.440 --> 00:21:41.920
<v Speaker 1>guest list.

465
00:21:42.000 --> 00:21:44.920
<v Speaker 2>That is an A and D condition, a compound logical

466
00:21:44.960 --> 00:21:47.440
<v Speaker 2>expression requiring two true values.

467
00:21:47.480 --> 00:21:50.440
<v Speaker 1>Exactly. So, you walk up to the door. The bouncer

468
00:21:50.519 --> 00:21:53.759
<v Speaker 1>checks your ID first, he sees you're only eighteen. He

469
00:21:53.839 --> 00:21:57.400
<v Speaker 1>denies you entry immediately. Crucially, he does not even body

470
00:21:57.480 --> 00:21:59.279
<v Speaker 1>looking down at his clipboard to see if your name's

471
00:21:59.279 --> 00:22:02.359
<v Speaker 1>on the guest list. All right? Why Because the rule

472
00:22:02.480 --> 00:22:05.559
<v Speaker 1>requires both to be true. Since the first one is false,

473
00:22:05.599 --> 00:22:08.240
<v Speaker 1>the whole thing is mathematically false. Checking the list is

474
00:22:08.279 --> 00:22:09.200
<v Speaker 1>a waste of energy.

475
00:22:09.400 --> 00:22:11.960
<v Speaker 2>That is precisely how the c compiler evaluates the A

476
00:22:12.000 --> 00:22:14.880
<v Speaker 2>and D operator. It evaluates expressions from left to right.

477
00:22:15.240 --> 00:22:17.200
<v Speaker 2>If the left side is false, the compiler knows the

478
00:22:17.359 --> 00:22:19.640
<v Speaker 2>entire statement cannot possibly be true.

479
00:22:19.440 --> 00:22:21.200
<v Speaker 1>So it stops, just completely stops.

480
00:22:21.240 --> 00:22:23.240
<v Speaker 2>It completely ignores the right side of the equation.

481
00:22:23.279 --> 00:22:26.000
<v Speaker 1>A short circuit on the surface that sounds incredibly efficient.

482
00:22:26.480 --> 00:22:30.160
<v Speaker 1>It saves a computer from wasting processing cycles. Why is

483
00:22:30.160 --> 00:22:30.720
<v Speaker 1>it a trap?

484
00:22:30.880 --> 00:22:33.480
<v Speaker 2>Because of those side effects we mentioned earlier. Let's look

485
00:22:33.480 --> 00:22:36.480
<v Speaker 2>at an example from the Silicus and Silicus textbook. Imagine

486
00:22:36.519 --> 00:22:40.039
<v Speaker 2>this line of code C equals in parentheses a greater

487
00:22:40.079 --> 00:22:44.200
<v Speaker 2>than fifteen, A and D in parentheses plus b greater

488
00:22:44.200 --> 00:22:44.759
<v Speaker 2>than fifteen.

489
00:22:44.880 --> 00:22:47.519
<v Speaker 1>Let's trace that the variable C gets the result of

490
00:22:47.599 --> 00:22:50.279
<v Speaker 1>checking if A is greater than fifteen, A and D

491
00:22:50.400 --> 00:22:53.319
<v Speaker 1>if the incremented value of B is greater than fifteen.

492
00:22:53.599 --> 00:22:57.359
<v Speaker 2>Now suppose A is currently ten. The compiler looks at

493
00:22:57.400 --> 00:22:59.440
<v Speaker 2>the left side of the A and D operator. It's

494
00:22:59.440 --> 00:23:01.519
<v Speaker 2>ten fifteen false.

495
00:23:01.400 --> 00:23:04.160
<v Speaker 1>And because it's an A and D operation, the compiler

496
00:23:04.200 --> 00:23:08.039
<v Speaker 1>becomes the lazy bouncer. It's short circuits. It completely abandons

497
00:23:08.039 --> 00:23:09.079
<v Speaker 1>the right side of the equation.

498
00:23:09.240 --> 00:23:10.880
<v Speaker 2>But look at what was on the right side, A

499
00:23:10.920 --> 00:23:14.440
<v Speaker 2>prefix increment plus plus B. Because the right side was

500
00:23:14.599 --> 00:23:17.279
<v Speaker 2>entirely skipped to the variable B is never incremented.

501
00:23:17.440 --> 00:23:20.039
<v Speaker 1>Wow. If I wrote that line of code, my human

502
00:23:20.079 --> 00:23:23.200
<v Speaker 1>brain assumes B will go up by one every single

503
00:23:23.240 --> 00:23:24.559
<v Speaker 1>time that line is executed.

504
00:23:24.599 --> 00:23:26.920
<v Speaker 2>But B only increments if A happens to be greater

505
00:23:26.960 --> 00:23:29.359
<v Speaker 2>than fifteen. If A is ten, B just stays exactly

506
00:23:29.400 --> 00:23:31.319
<v Speaker 2>where it was. You have just introduced a.

507
00:23:31.279 --> 00:23:32.839
<v Speaker 1>Phantom bug that's terrifying.

508
00:23:33.119 --> 00:23:35.920
<v Speaker 2>Your data is now misaligned, and it might not actually

509
00:23:35.960 --> 00:23:38.799
<v Speaker 2>crash the program until thousands of lines later when a

510
00:23:38.799 --> 00:23:42.200
<v Speaker 2>completely different function relies on B being the correct number.

511
00:23:42.559 --> 00:23:45.200
<v Speaker 1>So what does this all mean? It is a language

512
00:23:45.240 --> 00:23:48.240
<v Speaker 1>that truly demands you think like a machine rather than

513
00:23:48.279 --> 00:23:52.880
<v Speaker 1>expecting machine to understand your human intent. From compiler illusions

514
00:23:52.880 --> 00:23:56.880
<v Speaker 1>and fractional rounding errors to the terrifying reality of negative

515
00:23:56.960 --> 00:24:00.119
<v Speaker 1>numbers magically becoming four point two billion.

516
00:24:00.160 --> 00:24:02.680
<v Speaker 2>It's all rooted in that original design philosophy from the

517
00:24:02.759 --> 00:24:08.799
<v Speaker 2>nineteen seventies. C achieves raw, unparalleled performance by delegating all safety,

518
00:24:08.960 --> 00:24:12.519
<v Speaker 2>all memory management, and all logical verification directly to you.

519
00:24:12.960 --> 00:24:18.240
<v Speaker 2>It rewards surgical precision, and it ruthlessly punishes assumptions, which leads.

520
00:24:18.119 --> 00:24:20.880
<v Speaker 1>Us with a rather profound reality to consider. Think about

521
00:24:20.880 --> 00:24:24.119
<v Speaker 1>the physical infrastructure of our modern society. C isn't just

522
00:24:24.160 --> 00:24:26.240
<v Speaker 1>a historical curiosity.

523
00:24:25.640 --> 00:24:26.240
<v Speaker 2>No, not at all.

524
00:24:26.279 --> 00:24:29.079
<v Speaker 1>It is the foundational language for the world's operating systems.

525
00:24:29.359 --> 00:24:32.440
<v Speaker 1>It runs the embedded processors in medical devices like pacemakers.

526
00:24:32.640 --> 00:24:34.839
<v Speaker 1>It controls the anti lock brakes in your car, and

527
00:24:34.880 --> 00:24:37.039
<v Speaker 1>the avionics navigating commercial airspace.

528
00:24:37.279 --> 00:24:41.079
<v Speaker 2>It is running anywhere that requires raw speed and immediate

529
00:24:41.319 --> 00:24:42.839
<v Speaker 2>unrestricted hardware control.

530
00:24:43.400 --> 00:24:47.039
<v Speaker 1>So, given everything we have explored today, given how terrifyingly

531
00:24:47.160 --> 00:24:50.319
<v Speaker 1>easy it is to make an invisible mistake to miss

532
00:24:50.319 --> 00:24:53.720
<v Speaker 1>a single amper sand, to accidentally type a single equal sign,

533
00:24:54.119 --> 00:24:57.559
<v Speaker 1>or to force a comparison between assigned and unsigned integer,

534
00:24:57.759 --> 00:25:01.440
<v Speaker 1>how many undiscovered ticking logic bombs are silently running in

535
00:25:01.440 --> 00:25:04.319
<v Speaker 1>the background of our modern world right now, just waiting

536
00:25:04.319 --> 00:25:06.279
<v Speaker 1>for the exact right conditions to trigger.

537
00:25:06.400 --> 00:25:07.440
<v Speaker 2>It's a sobering thought.

538
00:25:07.640 --> 00:25:10.440
<v Speaker 1>Next time you are walking through that perfectly manicured digital world,

539
00:25:10.759 --> 00:25:14.559
<v Speaker 1>just remember you are surrounded by tripwires. Thanks for joining

540
00:25:14.640 --> 00:25:15.440
<v Speaker 1>us on this deep dive,