How One Line of Code Almost Blew Up the Internet

[@CrimsonGamer99]

I love how there's a team of literal wizards out there somewhere speaking ancient runic languages who have the power to delete the internet if they get a rune wrong.

[@jeffbrownstain]

Imagine the same but for all of reality 🤔

[@CtrlAltSHIT]

@@jeffbrownstain guys... I think I have my next D&D campaign.

[@VonKuro]

I will add a wizard hat sticker to my programmation laptop in memory of this comment.

[@girlswithgames]

these "wizards" were parsing HTML with regex lol. don't be too impressed by them. don't be fooled by all these fancy terminologies. that's an absolute rookie mistake and big fat no no lol

[@piotrkozbial8753]

@@girlswithgames What a stupid comment. This is exactly the right thing to do. How do *you* parse HTML?

[@recer_]

It sounds like an old engineer added the buffer to avoid a leak, but didn't leave notes on it

[@kevinfaang]

Pro engineering move: don't actually fix the issue, implement an undocumented hacky workaround that itself seems like a bug so that when someone else fixes the workaround they get hit with the initial issue

[@stoyanpetkov2488]

@@kevinfaang Now when you put it that way .. that is most likely what happened lol :D

[@kevinfaang]

To be fair though, I think it is unlikely they knew about the leak, given the rarity and impactfulness. I would chalk the empty buffer masking the issue up to coincidence.

[@brdrnda3805]

@@kevinfaang He was just placing an elephant in Cairo

[@darylphuah]

​@@kevinfaang I think its more likely the author of the code knew about it being possibility, so just put it there just in-case. Otherwise there's really no reason to have an empty buffer. The general rule when you see weird stuff like this is, "its there for a reason".

[@ryan8742]

Cloudflare deserves some more credit for how transparent they were about the issue

[@guiorgy]

Considering that Google and all the other caching services were involved, it would've come to light eventually hurting their trust even more, so they didn't have much of a choice

[@exploitenterprise6515]

They knew google would snitch

[@wowzerxx526]

They had to be

[@txic.4818]

theyre an infosec company lmao ofc they were

[@patryk4815]

look at bugbounty, they only pay max 3k$ ;) Soo it is wroth selling bug on black market

[@raffimolero64]

one thing my father always told me about iterators: "NEVER check index == end. ALWAYS check index >= end. You should never assume that your iterator is consistent and never skips over any values."

[@thisismygascan4730]

i was looking for this comment. it's not like == is any faster or more readable.

[@MatthijsvanDuin]

That advice taken at face value is bogus since many kinds of iterators only support equality-comparison, e.g. when iterating a linked list. But it's good advice if your iterator does support a total ordering that's consistent with iteration.

[@MatthijsvanDuin]

@@thisismygascan4730 == can actually be faster in some cases, since it makes it easier for the compiler to reason about the loop count, but yeah it _usually_ makes little to no difference

[@randomghost1080]

@@MatthijsvanDuin from my experience, nearly all instruction sets I've seen so far (AVR, MIPS, x86, ARM) take the same number of clock cycles for integral comparison (usually 1 or 2).

[@MatthijsvanDuin]

@@randomghost1080 It's not about the time taken to a literal == or >= comparison, it's about enabling the compiler to do loop transformations.

[@caltissue141]

As a dev, I'm not sure if I'm comforted because this stuff can even happen to a company like CloudFlare, or horrified for exactly that reason.

[@fulconandroadcone9488]

That is why we invent safety things. Sure you can operate this machine without such and such guard, but just know for every smart one that can there is dum/drunk/exhausted/stressed someone else that will get chewed up if this machine can operate with someone in eye site distance.

[@nickstegman8494]

@@fulconandroadcone9488 Sometimes, the smart one is also the exhausted and stressed one (also, smart people can be drunk, though hopefully only during hobby projects). I mean, I don't know about you, but whenever I'm too sleep-deprived, the quality of my work generally declines.

[@fulconandroadcone9488]

@@nickstegman8494 my guess is if that if you disregard basic safety which includes disabling safety mechanism during normal operation you might not be as smart as you think you are

[@austint1151]

​@@fulconandroadcone9488 you've never worked while severely exhausted. Not a programmer, but in any field exhaustion leads to dumb basic mistakes. Example, I was exhausted the other night after a 16hr shift, made some cereal for quick dinner, and put the milk in the pantry and cereal in the fridge.

[@n1n1_37]

We're only human, after all🗿

[@S.B.K.7746]

The more you learn of the Internet and its overall supporting structure, the more you'll realize how fragile it really is and how terrifyingly easy it is to make it crumble.

[@TheTransitmtl]

It's a literal jenga tower. We all use packages that use other packages tgat are all maintained by unpaid individuals.

[@rajatsingh2956]

As an electrical power engineer, I would implore you to take a look our electric grid, and you will feel way better about the internet! 😅

[@JoshSweetvale]

Hardly. It's easy to knock down the modern HTML standard, but the basic adress system and the pysical network are very robust.

[@CubeInspector]

​@@JoshSweetvaleuntil you learn about operation cyberpolygon being ran by the same people that ran event 201 right before covid

[@JoshSweetvale]

@@CubeInspector There's no-one at the steering wheel.

[@Pence128]

There are three hard problems in computing: cache invalidation, naming things, bounds checking, and hunter2.

[@dastyp4771]

That one took me embarasingly long to get

[@jessveness]

Cleverrr

[@rosyidharyadi7871]

lol. nice one

[@pandaszan9310]

I like this one xDDD

[@luisderivas6005]

boundary checking is not that hard, but it does but into CPU cycles.

[@sahaakhiyat3703]

The title was intriguing and video was so interesting that I didn't even notice that video has 54 views from such small channel with 157 subs. Good job :D

I didn't realized that too until I read this comment :D Really good content.

[@Gabriel-wq4ln]

2 days later and the channel has 1270 subs

[@Anonymous-XY]

Now 1.46K subscribers Edit: Now 4.01K subscribers Edit2: 6.04K subscribers

[@user-lj4lo7cx7m]

Now 2.2k

[@user-lj4lo7cx7m]

Update: 3.2k

[@ilgattoparddo]

You managed to make a overly technical topic very interesting instead of boring! Never saw anything like that before.

[@christopherg2347]

So it was the time honored, decades old combination of: - working with naked pointers - not checking if you reached the end - foolishly trusting that input from a network source _isn't_ garbage Calling it "Cloudbleed" is fitting, as Heartbleed had all of those as well :)

[@JorgetePanete]

I wish HTML in browsers was actually checked before any representation to force developers to simply make them good

[@luisderivas6005]

Never trust input for the en user - period. Garbage in - Garbage out. Not too long ago I fixed Non-Ascii chars bombing a piece of middle-ware, all because the commercial devs for the input system never though users would cut and past content from the Internet into a comment field. Nor did they properly set the XML declaration for the output file to specify the character set!

[@LilacMonarch]

*not checking if you reached or overshot the end. the check should have been >= not ==

[@williamdrum9899]

More like an off-by-one error

[@christopherg2347]

@@williamdrum9899 This was off by a _lot_ more then one. And also you were off _with a pointer_ - which is why you should not work with naked pointers unless you really need to go low level.

[@CottidaeSEA]

This also shows a different common issue with loops, where the exit clause is an equal value. Sure, you might expect the incremented value to eventually always reach the desired value, but the safer thing to do in this case is check if it's higher or equal. I would likely write it as less than, but depends a bit on what the surrounding code looks like.

[@WackoMcGoose]

Was gonna point out the same thing. Never assume an incrementer value will always eventually _exactly equal_ a target value, any number of things (race conditions, cosmic ray bitflips, floating-point fuckery, ancient mummy-curses, etc) could cause it to somehow "miss" the intended exit value.

[@soxic-y8e]

@@WackoMcGoose Ancient mummy-curses is my new excuse for issues in code 🤣🤣

[@WackoMcGoose]

@@soxic-y8e Well, once you've ruled out race conditions (because you're using a language that enforces thread safety, or your code isn't multithreaded to begin with), cosmic rays (because your server uses ECC memory), and floating-point fuckery (because you're using integer vars), at that point it's time to look into supernatural root causes. ...Honestly, I'm surprised there _aren't_ more COEs containing the phrase "Return the slaaaab..."

[@cassinihuygens1288]

Checking for equality would be the normal case. If the index is beyond the upper limit, that should trigger some form of assertion so the root bug is fixed, not masked.

[@CottidaeSEA]

@@cassinihuygens1288 Sure, but preventing hell from breaking loose is more important, you can always add logging after breaking out of the loop in case shit hit the fan. I'm not saying you shouldn't deal with the issue, I'm saying you should ensure the code runs as expected even when failing. A small addition; it would be better to check if the value exceeded the expected value outside of the loop regardless for quite massive performance reasons, since a loop like this will run so many times that a simple if-statement will slow it down significantly. It is also not necessary to check it until after the loop has been exited as it couldn't have been above it prior to that. So regardless this is how you'd do it.

[@conkerconk3]

I didn't really think a HTML/XML parser was _that_ hard to implement, but i never even thought that it basically is just a giant state machine, where different characters can change the entire state in many different ways, and managing that is nightmare inducing

[@robrucki6695]

you don't actually write the state machine, that code is generated

[@arjix8738]

Any parser can be a state machine. The fact that it is a state machine is just an implementation detail.

[@luck3949]

A layer of abstraction is missing in the description. A finite state machine is indeed used in many modern approaches, but they are usually auto-generated from a more human-friendly parser description. So the finite state machine remains under the hood, invisible for the end-user (programmer). Do you know regexp? In classic implementations finite state machines are generated from regexp, and then used to do the parsing.

[@MrMudbill]

You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts.

[@cameron7374]

And the HTML parser needs to be able to turn itself off temporarily when it finds a element.

[@tc2241]

Your presentation and use of case studies to make something as mundane as reviewing code somehow made for a downright entertaining watch. Subscribed!

[@nocturne6320]

This is the reason why I always do >= than just == comparison, you never know when an accidental off by one error might occur

[@superironbob]

An empty buffer as a terminator of a buffer filled with null terminated strings is common enough pattern to be named: double null terminated buffers. But it's also weird enough that even when its used it's often not consistently produced or consumed.

[@algorythm4354]

Cool info! A lot of people here are assuming it was some design quirk

[@bazoo513]

Now, this was _very_ instructive, and, to this old hand who committed every imaginable blunder under the sun, very relatable. Thank you!

[@TheStiepen]

This is a really great video. It explains the situation really well and easy to understand. I also massively appreciate how you put footnotes in the description.

[@inventorxtreme]

I finished watching the video and thought that you would have at least 100k subs. Keep making great content and you will definitely go far!

[@keco185]

If you’re ever waiting for something to increment until it equals a value, it doesn’t hurt to have an “else > value” block that throws an error to let you know something went wrong

[@fehsilva4868]

This channel is so underated omg I can't even believe that a small channel can produce so much quality content, keep going bro, you're going long ways ❤

[@AndersHass]

Based on the voice I think it’s the same guy behind Fireship Edit: After listening to Fireship again I can hear a difference in the voice, and Fireship also shares a channel called Jeff Delaney which I would think is his personal channel.

[@fehsilva4868]

​@@AndersHass I don't think so, it has some similarities but I don't think it is the same guy behind fireship

[@jonwallace6204]

As a QA software dev, my job is to write the program that runs our automated tests as well as hunt down bugs in the code the regular QA guys find. Kudos for making an entertaining video out of a bug hunt. I have had some looooong hunts. Requiring a very specific type of bad input is really hard to figure out, I often end up stepping through the debugger trying to think of if any of the possible branches would fubar me.

[@chupasaurus]

I have a fun bug report for you. Devs on project come up to me saying that Cassandra DB rejects a basic SELECT query on data of a certain user, and they can't see the entire stack trace because of logs are masked on production. I try the query and see that JSON parser returns with "index out of bounds" while constructing the array of integer IDs from the result! By removing numbers from the end of it and looking up the source code of the parser used by the database, it turned out that the hacky ICPC-style was failing on a combination of the first 3 numbers pushing the index into thousands.

[@hb1338]

I became a much better software engineer the day I joined a small company where it was standard practice to stay at work until the bug that was blocking process was fixed. I wasn't there very long before I became very adept at identifying possible error conditions. As you suggest, a good debugger is an essential tool because it shows you all the things you didn't think about.

[@AT-rw3ou]

@@chupasaurus Exhaustive scenario walk-through during code inspection could have weeded it out before it got into the final product, but it depends on the caliper of the code inspectors.

[@bumbleguppy]

The QA community should self publish a monthly magazine only filled with bughunts from devs out i the trenches like this video. Like veterans telling war stories at a bar, imagine all the little things you could pick up along the way over the years.

[@effuah]

The evil part comes, when running the debugger changes how the program is executed, for example when the bug comes from a race condition and running the debugger naturally makes the code run slower.

[@unlisted9494]

I've been on KZbin since it was Google video and I've never seen a video description like yours, good stuff, this video presentation goes tough as nails, I salute

[@noahkrause6607]

Well done, Kevin. This was extremely well made. Loved it!

[@noceur9102]

This video and channel deserves so much more recognition. I'm almost halfway through the video and it's so well put together. Good wishes and I cannot wait to see you get the views you deserve for the effort put in. ♥♥♥♥

[@AT-rw3ou]

Kudos for isolating and fixing the problem successfully in short order. Really like the video, well made and fun to watch.

[@chrisnguyen180]

New favorite channel; love the high BPM background music, visuals, concise yet detailed explanation, overall format/structure, the Michael Bay explosions every 5 seconds, etc.

[@thetuerk]

8:09 the humor in this little animation is simply sublime. Made me giggle while watching at 1 am

[@zavhytar9333]

I really appreciate how this guy has all his assumptions, corrections, etc, in the vid description.

[@FlygisTheFlygis]

Kevin! Just stumbled on this video and was watching until 5:00 before noticing that your channel is tiny. How are you this good at this humble size! Big ups to you my man. Thanks for the content

[@draakisback]

This is where documentation becomes important. If the developer who implemented the empty buffer had explained why they needed it, maybe this wouldn't have happened or at the very least they could have figured out a way to circumvent the problem when they were first rewriting the HTML parser.

[@ferociousfeind8538]

But there's always the chance the buffer was perhaps entirely accidental (smells like an off-by-one error to me, instantiating one too many buffers for our purposes) rather than actually covering up this other off-by-one error in the other parser

[@draakisback]

@@ferociousfeind8538 naw, I don't think it was a one off. They had deliberate functionality in there were the system would chunk html docs and the final doc in the buffer was always empty. That empty buffer chunk was like a carriage return in a way. The closing tag of the HTML indicated the end of the doc but if the doc doesn't have a closing tag, the lack of characters in the following buffer would work as a flag that basically tells the parser that this is the end of the doc. It's obvious that this was done deliberately but the reason is a bit vague as to why exactly they did it this way. Hence why documentation would have been important. When they migrated from the old parser, they obviously didn't take into account the edge case where the HTML is broken and they removed the empty chunk without adding logic to handle the usecase.

[@pvic6959]

this is why i write my thought process for most things. espically if its "clever". forget someone else. *I* need to remember what I did and why 2 months later when I look at it aagain lol

[@connorwelsh1]

this aged well

[@Ali-in-the-goblin-cave]

I was super surprised when I saw that you didn't have atleast 100k subscribers because of how high quality this video is. Great job!

[@JGHFunRun]

I always feel uncomfortable seeing/doing something like p == pe to check if the end has been reached, interesting seeing those fears validated. I always do p >= pe, and add assert(p

[@KSPAtlas]

I figured that out myself while programming, I thought "how am I *sure* this index will be ever equal to the limit?"

[@hehe-te7ed]

I've been looking for videos like this. Tech/software story telling. I loved your delivery, hope to see more from you. Subscribed!

[@jennytalia8224]

TLDR: Buffer overrun in some legacy parser.

[@jademonas]

"debugging and rethinking life" im going to start using that

[@dooza]

Got this in my feed with only 20 views. Usually I always skip those, but I gave it a chance. Great quality on the video, don’t think you’ll not be big one day.

[@regolithe]

I speak english. I did not understand a single word in this video. I watched the whole thing anyway.

[@pacigisto]

This video was super good and well-made! I don't know how to describe it, but it just felt good to watch. The visuals were just so satisfying, and I especially liked 6:51. I also really appreciate the sources, assumptions, and corrections in the description! Many big KZbinrs don't cite anything and go by the philosophy of "well you shouldn't trust me entirely anyways so it's not my fault if I misinform you." Subscribed and liked, great video!

[@SilnyDuke520]

^ this++++++

[@gustawbobowski1333]

@@SilnyDuke520 doesn't compile

[@arabidllama]

The extra buffer at the end feels like a band-aid fix that never got documented

[@24can22]

This form of content has great potential for your channel. good work

[@TheMorphium]

Had some code break once after an update. It was the update that exposed an old bug that hadnt been caught. I can see how things like this happen.

[@fulconandroadcone9488]

Those can fun, what is not fun is having an issue and purposefully ignoring it until it bites you in the non of the pleasant areas.

[@sankeethganeswaran3024]

wtf lol i clicked on this and watched it the whole way thru thinking it was from some big tech channel but it only has 984 views. lol good vid bro

[@Droftals]

I work on systems that address network vulnerabilities for AWS, and you did a good job here.

[@deletedaxiom6057]

I just found your channel, must say I am impressed and like the content. I have a CS and Mathematics degree, and most channels don't give a deep enough dive or are just too cornflakes with water dull to pay attention. Thanks for the content

[@brianreece2120]

very entertaining and educational! your combination of humor and narration is great

[@austingoodrich2193]

I got recommended this video, first time I've seen your channel and I gotta say I enjoyed this video. I'm now subscribed 👍

[@nothingtoseehere93]

A buffer overflow because of memory unsafe languages like C??? I’m shocked! I can’t believe it!

[@kanbekan]

Such informative video! It's easy to follow and it taught me to value backwards compatibility more. I hope you get more views! Also kinda surprised to see Mr. Affable there

[@oru]

mr affable is everywhere

[@joseph0x45]

How did I not know of this channel before? Great video dude

[@cppguardian4113]

I have never been more proud to know that as a c++ dev I will always be needed because legacy moon runes written 30 years ago will inevitably fail when some obscure pointer spills over into undefined memory.

[@tomhekker]

You just popped up in my recommendations! Great video!

[@MarkVrankovich]

Wow. I can't imagine the time it must have taken to make this video. Well done.

[@SlickHF]

wonderful production quality from such a small channel keep it up man

[@iphonecharger4185]

well, this aged well

[@robschn]

Dude I work in CDN and you explained everything perfectly, great work!

[@raynjpg]

Where do you work? Is it a worthwhile job? I'm just getting started on my Comp Sci degree and still exploring and researching my options.

[@Fudwinkle]

I had a stupid bug last month, that heavily degraded performance, also happened Friday night. I had added a new caching solution some years back (one I wrote), and after 1,5 years flawless performance, I added more usage. This tipped the scales, and the caching storage was exhausted. I then remembered I forgot to add a flush of storage in this case, so it got full and all new requests failed. I quickly added a flush, only a few hours later, but this was only a bandaid; it'll fill, flush, fill. So after some quick sleep with a fever from the flu that I had, I realized the cause (it was added to something unique, causing every call to create a cache with no hits, at 1+ mil transactions per second), so I deleted the caching at this point and it flowed again, phew. Cause? A design change. The caching point WAS a good non-unique place for 6 months in development, but during bug testing, someone altered it, so it became unique. And I had already done the tests for performance at scale, so it just wasn't noticed 😬 Luckily it was hardly noticed by anyone, but it could have been truly terrible. I work in a bank, and the finance engines was grinding to a halt. A process that runs some critical financing was still running after having used 16+ hours! After my hotfix, we terminated it and restarted, and it took 2 minutes (as it should) 😳 If I wasn't sick with a fever, I could likely have reacted faster, but thinking in that condition was as slow as a caching bottleneck 😂

[@gustawbobowski1333]

Sounds fake.

[@freedomgoddess]

@@gustawbobowski1333 cool

[@Saisujal_11]

What did you major in or how to do learn this?

[@marklonergan3898]

"why was an empty buffer added? No reason" I can almost guarantee that was a developer that thought "someone will inevitably do something dumb. Lets make sure there's nothing beyond the last buffer"... and the developer that removed it thought "this system must be perfect - no overhead. It's not like anyone's going to try read beyond the last buffer".

[@SuperShadowP1ay]

Great video! The silly sound effects were beautiful; they're what I imagine in my head when doing my own programming :)

[@kranhat]

Thank you for adding the credits, you are the best!

[@ViniciusNegrao_]

I've learned to add a >= instead of == even if you always expect the pointer to never get past the target, cuz you never know, right? This could've prevented this from happening as well

[@Axodus]

Yes, only add == when you truly only want to run your code when the variable is exactly that value, if the code can accept higher values there's no point not using >=

[@EstebanGM245]

This video is amazing! You deserve much more popularity.

[@lazareric]

The only problem I see with this, is how the f, didn't they have 100% test coverage, with something this important, if they had proper test use cases, they would instantly catch an issue, with the new parser implementation. It's insane that this important digital companies don't do the most basic coding practices, it's just mind boggling to me.

[@anujmchitale]

No company can reach 100% test coverage. Seems you don't know how any important software is patched together in the real world. 😁 It's all a patch work. No software can be defect free.

[@latedriver9019]

1.4k... I expected this channel to have at least 100k. Great video man, you're making it into the algorithm!

[@davidmartensson273]

Which is why when having range checks you should not test for equality but equal or greater/less, that way a one off error can only catch one extra char. Yes it will cost performance, but if that is unacceptable, you need to have much better understanding. The extra empty buffer seems in my opinion as a big red flag, if its explicitly added and not just a result of an one off error it probably served a purpose and should be thoroughly documented, or refactored/re-engineered into something less obfuscated. This is why I always encourage curiosity and ask all new devs to make sure to question any code they do not understand, if a more experiences dev cannot explain it in an understandable way its probably wrong, or at least bad code that should be rewritten :)

[@pythusiast4701]

awesome research work dude!!!

[@Jack-hk4nn]

10:20 Usually, if some code looks dumb, or inefficient, it’s because some software engineer before you working to a deadline had to get something out fast, not clean- and there’s probably a good reason for that “empty buffer” 😂

[@NEOOOOOOON]

this style of video is great. you should do more of this

[@_GhostMiner]

8:54 and that's why >= or

[@toshimichi]

I love your editing style. nice vid!

[@3zachm]

This is kinda like a crime doc but for software engineering and I'd gladly watch much more

[@TheTrueMissingLink]

I love how you synced up some of the animations with the beat

[@danielw4778]

0:31 oh shit I remember reading that tweet and thinking:"well someone's about to have a shitty day"

[@edge_case]

This channel is awesome, man. Props. You deserve far more subs.

[@ligamo2615]

Absolutely incredible video. Thank you.

[@originellerNickname]

Got this in my algorithm, and really liked the video and the way it was narrated! :)

[@deidara_8598]

This is very common for how memory bugs occur in software. One programmer makes an assumption as to how the memory works, and writes their code accordingly, then some other programmer changes some other piece of code that makes it so those assumptions no longer hold, and voila, you have a bug.

[@trevise684]

great sound quality and recording. already better than most other channels

[@Dexter101x]

I used to have a website, full of scripts that were poorly coded by me. It was full of unfinished tags i.e. those that weren't closed properly. It could have caused the whole internet to collapse if my website was visited by a lot of people

[@daumienebi]

?

[@kenkioqqo]

For a moment, I thought this was the voice of Fireship. Then I remembered Fireship narrates extremely fast. Awesome content.

[@asagex]

>= is always better than == when dealing with loops

[@ali_xD_]

holy shit bro this vid is so good i thought you had like 100k subs but only 6k? damn you deserve some recognition

[@OrangeC7]

10:50 That's horrifying.

[@pxlnghtt]

Congrats on 4k subs, great video!

[@MuseNetEnthusiast]

I was so confused when i heard the Discord ping sfx lmao

[@airsoftgunjk]

The inclusion of the empty buffer at the end of the previous version sounds like a hack fix that someone forgot about.

[@nothayley]

This is a fantastic video. Wonderful explanation that I think even someone who never saw a line of code might understand

[@TheHTMLCode]

Stumbled on this channel today, top quality content! Thanks 😄

[@bomono3973]

keep making videos like this, this video was amazing, absolutely loved it.

[@davidrose2899]

Thank you for including the artists you used in this video.

[@Wish13]

Happened again with CrowdStrike..

[@vichav3167]

Back at my college we have been told to use => or =< for buffers for exact same reason. This precise condition (++p == pe) is based on assumption that p will always be incremented by 1 and never will be incremented by 2. But actually there is possibility it will be incremented by 2 or even more. Simple use of (++p >= pe) will actually fix issue, and prevent it from happening. It reminds old exploit of buffer overflow somehow. The reason may be bugs in this or other code, sun or other radiation make bit from 0 to 1, malfunction of memory or registers, etc.

[@PROJEKTSYNTH]

1:20 thats why I never received my parcel!

[@ViniciusNegrao_]

Famous last words... "I don't need to add documentation, this feature is so clear everyone will get it"

[@benyseus6325]

Pointers as always being the bane of coder’s existence.

[@williamdrum9899]

Corporate needs you to find the difference between this pictures: Pointers, array indices, references Assembly programmers: "They're the same picture"

[@NuliTV]

Didn't expect to see Mr Affable himself in the wild like this. Great video mate.

[@AlexGarcia-kg9pw]

Is that Brian McElhaney of Britanick @0:13???

[@dizz1934]

Bro went from telling a simple story to nuclear launching algorithms

[@Yutaro-Yoshii]

conclusion: writing parsers safely is confusing and difficult

[@bytefu]

Mostly if you're using C or C++.

[@Yutaro-Yoshii]

​@@bytefu Yeah. imho functional programming languages are the best kind of language to code a parser in. I've coded a json parser in scheme before and that was a breeze. All I had to do was to slice up the string and pass it down to offspring functions. Having no shared buffer and not having to think about pointers and memory life cycle puts a load off the mind.

[@lhpl]

Not at all. Doing it with C pointers is problematic though. (And I am not sure, is HTML even parseable at all - in a strict sense - these days?)

[@Yutaro-Yoshii]

@@lhpl Do you mean "parsable" by being context sensitive? Or belonging to some parsing class like LL and LR?

[@OnionManSteve]

I have absolutely no idea what you're talking about, but your voice is super relaxing and great background noise