From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 304CC3858C52 for ; Sat, 4 Feb 2023 17:01:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 304CC3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x32d.google.com with SMTP id u10so2895236wmj.3 for ; Sat, 04 Feb 2023 09:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=+08PV5XexL04JgQ9ah2eP//Oxi4vDLPV1jMyumIdq0E=; b=lm9n+uXv7/NJAFiewmkSVKA0pGcgubIQzJZSHfwQtJ5xh4IjcjuPHLzkcW/0W+eabK 404NaagrNUkhVIBRJIQYdYSRzDB9id3xy0NE/X1r6IVVCLdLeTtVSttJpIQmmOZULqxN DHLYH3tEVZPM9SO58PtppsxCtSlQWoyApWXEKjB/kfETpOW2uwW3vhetNE9c22bozLRs Cfe1dKi6gLyaqUkdAMukRcONGjl+Q4WYjvRVTSL3Xt2Z7e6R+ASZNngWYJVpCSatAaoU XdwfX9J6bIaEF7Ir9VXf5ELVVJdmKyxj7iu9awohW3bFSBFoOCFecG2EHAQ1MBQ7XKSp DpYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+08PV5XexL04JgQ9ah2eP//Oxi4vDLPV1jMyumIdq0E=; b=dYnjZvyZtCvOvcu74lhgx/LgmiDj6AvZm4xs2aU95F8PMrR3OHXtv4ZJkmIdbnN+5K JCeOOjgU1rZ2KhXIpSyvDIrAb1VSqA93N3GiKdZ7TZPvmD+s9m8rcRCds5IGmXwP7lN/ uIYwNwi7PKFctvYy7I4Had5zLoI1bLXLJZ0wYwhVGRncZoNCGCUnwPX+Ufz3kbhfhfPh Wgs8nKvvKWRzhCljHjVQrIT9zhPAb7ZwXKo3c2d7xAe9pY7tcW1ZW4ihm23lyByGjCdf nDtlZyF44/sHJLjMOuqSeRrDSkQQ855WqPUEzhz2ODLogEHCrvhyxzcwM5mqP2DOR6YU krWQ== X-Gm-Message-State: AO0yUKX7H2yZBDmxgk2gowTMn9a+eDZindaGOQXp/1TamTeVq7zG77Sv AE1qUkJs9lgsE2qsFjXu/NtcoZW/w+vzVKK4YjqROBCoYT8= X-Google-Smtp-Source: AK7set8x3eHUqedGbOBOZ4AlphJsLA5YAEWZQYJPIo6lxV3/ht4UgXES0eD/FLu9bwcyYsz24QlSvFpMjTz81zn7qFo= X-Received: by 2002:a05:600c:4e01:b0:3df:f127:ef64 with SMTP id b1-20020a05600c4e0100b003dff127ef64mr173626wmq.26.1675530060407; Sat, 04 Feb 2023 09:01:00 -0800 (PST) MIME-Version: 1.0 From: Christopher Bazley Date: Sat, 4 Feb 2023 17:00:49 +0000 Message-ID: Subject: _Optional: a type qualifier to indicate pointer nullability To: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="0000000000000fa8fc05f3e2be3c" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000000fa8fc05f3e2be3c Content-Type: text/plain; charset="UTF-8" In August, I had an idea for a C language extension to improve null pointer safety. The tl;dr is that whereas a pointer-to-const may have undefined behaviour on write access, a pointer-to-_Optional may have undefined behaviour on read or write access. I shared this proposal with my colleagues, many of whom offered feedback and suggested improvements. Having finished prototyping my idea in Clang and experimentally applying it in a large closed-source codebase, I recently submitted a paper (n3089) to the WG14 committee in charge of C standardisation for ISO: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3089.pdf I also wrote an article explaining every aspect of my design and prototype: https://medium.com/itnext/why-c-needs-a-new-type-qualifier-61ad553cbe71 (long! sorry) I had hoped that a working prototype would help further my cause, but the code owners for Clang have just rejected my patches: https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/ Obviously, I am disappointed -- not only because of the huge amount of thought and effort I put in, but also because I genuinely believe in the potential of my idea to transform C programming for the better (particularly when compared to the alternatives). In my experience my prototype works better than Clang's existing solution in the same problem space, yet its implementation is orders of magnitude simpler. Some of the issues with Clang's nullability qualifiers are bugs; others are more conceptual. I raised some of the issues I found in another thread: https://discourse.llvm.org/t/nullability-analyzer-doesnt-seem-to-work-and-how-to-fix-it/ Does the lack of support for Clang's nullability qualifiers in GCC indicate a greater likelihood for my proposed feature to be accepted into GCC? I am determined to avoid putting a huge amount of my own time into another inplementation, only to have it rejected again. If my proposal has little value to you (quite likely, if you are a C++ programmer), please bear in mind that it is just a simple tool (like 'const') that individuals can choose to use, or not. It entails only a minor change to the semantics of one operator. Yes, it is contagious, but nobody will be forced to use _Optional in their project, and it is easy to hide using a macro. I don't feel that it deserves to be killed at birth. Please could someone direct me to the process and/or gatekeepers responsible for allowing such an extension into GCC. Thanks for reading -- Christopher Bazley -- Christopher Bazley --0000000000000fa8fc05f3e2be3c--