Live data from Hacker News

Viewing profile — msebor

msebor

HN member
Joined
Mon, Apr 13, 2020, 4:44 AM UTC
HN karma
117
Public activity
24 items

About msebor

No profile information was provided.

Recent public activity

  1. comment
    Comment #22870666

    I'm not aware of recent proposals for those but we have discussed ideas along those lines (closures: N2030, C++ lambdas, Apple Blocks: N1451, and I think there was one from Cilk). …

  2. comment
    Comment #22870519

    I'd expect a proposal for (1) to be well received. The only proposal I recall that deals with (2) is http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf . I think it's still …

  3. comment
    Comment #22870406

    WG14 in general looks favorably at proposals to align C more closely with C++ (within the overall spirit of the language) and I'd expect (1) would viewed in that light. I'd also sa…

  4. comment
    Comment #22870289

    Several of us discussed typeof and I'd expect a proposal for a feature along these lines to be well received. (I recall someone even saying they're working on one but that shouldn'…

  5. comment
    Comment #22870246

    There are many improved versions of string APIs out there, too many in fact to choose from, and most suffer from one flaw or another, depending on one's point of view. Most of my r…

  6. comment
    Comment #22868594

    C17 doesn't look much different than C89. If you are used to K&R C there may be some adjustment but I would expect it to be manageable. What might perhaps be more challenging is ad…

  7. comment
    Comment #22868486

    First, there needs to be a proposal for adding a feature (I'm not aware of one having been submitted recently). Second, any non-trivial proposed feature needs to have some existing…

  8. comment
    Comment #22867979

    memcpy and memmove aren't special. The part that discusses the copying of allocated objects is 6.5, p6, quoted below: The effective type of an object for an access to its stored va…

  9. comment
    Comment #22867797

    This is a good example. Let me flesh it out a bit more to illustrate a specific instance of this problem: int a[2][2]; int f (int i, int j) { int t = a[1][j]; a[0][i] = 0; // canno…

  10. comment
    Comment #22867653

    This is a common misconception (or poor way of phrasing it, sorry). Compiler implementers don't go looking for instances of undefined behavior in a program with the goal of optimiz…

  11. comment
    Comment #22867422

    An object of any type, initialized or not, can be read by an lvalue of unsigned char (or any character type). That lets functions like memcpy (either the standard one or a hand-rol…

  12. comment
    Comment #22867110

    Yes, it's undefined. It involves a read of an uninitialized local variable. Except for the special case of unsigned char, any uninitialized read is undefined.

  13. comment
    Comment #22867068

    Most of us on the committee would like to see more participation from other experts. The committee's mailing list should be open even to non-members. Attendance by non-members at m…

  14. comment
    Comment #22866996

    Casting between the three character types is safe and doesn't violate aliasing rules. In addition, objects of all types can be accessed by lvalues of any of the three character typ…

  15. comment
    Comment #22866929

    Yes, both :) There are a few in public domain that might be helpful to experiment with. Clang has had a static analyzer for a while and GCC 10 adds one as well (and the maintainer …

  16. comment
    Comment #22866870

    Robert's upcoming book has a survey of a few popular IDEs.

  17. comment
    Comment #22866845

    The ELF visibility attributes solve the part of the problem at the binary level (by hiding private library APIs from the application). The rest should be doable by structuring the …

  18. comment
    Comment #22866782

    The committee has reviewed a proposal (document N2360) to for const-correct string functions. But making function signatures const-correct solves only a small part of the problem. …

  19. comment
    Comment #22866519

    The C charter and the C committee's job is to standardize existing practice. That means codifying features that emerge as successful in multiple implementations (compilers or libra…

  20. comment
    Comment #22866415

    Some implementations have been making a lot of effort to do just that. GCC in particular has been adding these types of checks (either as warnings or sanitizers) in recent years an…

  21. comment
    Comment #22866288

    There are "projects" underway to clean up the spec where it's viewed as either buggy, inconsistent, or underspecified. The atomics and threads sections are a coupled of example. Th…

  22. comment
    Comment #22866180

    Some instances of undefined behavior at translation time can effectively be avoided in practice by tightening up requirements on implementations to diagnose them. But strictly spea…

  23. comment
    Comment #22866039

    That doesn't seem likely. There have been no proposals for anything like it and there is a general resistance to subsetting either C or C++ (the exception being making support for …

  24. comment
    Comment #22865928

    Fixing minor bugs or inconsistencies and reducing the number and kinds of instances of undefined behavior are some of the efforts keeping the C committee busy. Reviewing proposals …