CppCon 2017: John Regehr “Undefined Behavior in 2017 (part 1 of 2)”

แชร์
ฝัง
  • เผยแพร่เมื่อ 21 ต.ค. 2024
  • CppCon.org
    -
    Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/Cpp...
    -
    Undefined behavior is a clear and present danger for all application code written in C++. The most pressing relevance is to security, but really the issue is one of general software correctness. The fundamental problem lies in the refusal of C++ implementations (in general) to trap or otherwise detect undefined behaviors. Since undefined behaviors are silent errors, many developers have historically misunderstood the issues in play.
    Since the late 1990s undefined behavior has emerged as a major source of exploitable vulnerabilities in C++ code. This talk will focus on trends in the last few years including (1) increased willingness of compilers to exploit undefined behaviors to break programs in hard-to-understand ways and (2) vastly more sophisticated tooling that we have developed to detect and mitigate undefined behaviors. The current situation is still tenuous: only through rigorous testing and hardening and patching can C++ code be exposed to untrusted inputs, even when this code is created by strong development teams. This talk will focus on what developers can and should do to prevent and mitigate undefined behaviors in code they create or maintain.
    -
    John Regehr: University of Utah, Professor
    John Regehr is a professor of computer science at the University of Utah, USA. His research group creates tools for making software more efficient and correct. For example, one of his projects, Csmith, generates random C programs that have been used to find more than 500 previously unknown bugs in production-quality C compilers.
    Outside of work John likes to explore the mountains and deserts of Utah with his family.
    -
    Videos Filmed & Edited by Bash Films: www.BashFilms.com
    *-----*
    Register Now For CppCon 2022: cppcon.org/reg...
    *-----*

ความคิดเห็น • 12

  • @annazolkieve9235
    @annazolkieve9235 4 ปีที่แล้ว

    Excellent informative talk describing details of the UB! Very useful! Many thanks!

  • @Kobold666
    @Kobold666 24 วันที่ผ่านมา

    sizeof(int) is equal to sizeof(long) no matter if it's a 32bit or 64bit architecture. They changed int from 16bit to 32bit, but never to 64bit.

  • @gubgubbubbub
    @gubgubbubbub 4 หลายเดือนก่อน

    Excellent speaker and content!

  • @rafalmichalski4893
    @rafalmichalski4893 4 ปีที่แล้ว +1

    Is it possible to have UB during compile time (assuming no compile errors) ?

  • @hl2mukkel
    @hl2mukkel 7 ปีที่แล้ว +1

    Fantastic talk, highly interesting!

  • @cocomonkilla
    @cocomonkilla 5 ปีที่แล้ว +1

    Awesome lecture

  • @thought2007
    @thought2007 7 ปีที่แล้ว +3

    9:12 - Why can't the Standard just say "this is implementation-defined"? The example explains UB vs. defined, but doesn't explain the advantage of undefined vs. implementation-defined.

    • @Zeturic
      @Zeturic 5 ปีที่แล้ว

      Because UB isn't just at the language level. An architecture could exist where shifting too far is undefined, even at the hardware level. By listing it as implementation-defined rather than undefined behavior, C/C++ implementations on that architecture would be forced to add to gracefully handle that case in software every time there's a shift.

  • @BillyONeal
    @BillyONeal 7 ปีที่แล้ว +3

    The memcpy example is the standard being stupid. We should fix that.

    • @BillyONeal
      @BillyONeal 6 ปีที่แล้ว +1

      _moonPtr 1. I mean it should be fixed in C.
      2. Allowing more things doesn't break backcompat anyway.

  • @omfgbunder2008
    @omfgbunder2008 5 ปีที่แล้ว

    Shouldn't 32bit

  • @n3whous3
    @n3whous3 5 ปีที่แล้ว

    Wouldn't be better to write the subtitles with somebody who is in the business? "Valgrint", j.f.c.