[libc-commits] [libc] [libc][docs] Updates implementation status for some preexisting docgen json files (PR #89281)

Michael Flanders via libc-commits libc-commits at lists.llvm.org
Thu Apr 18 11:25:38 PDT 2024


================
@@ -1,29 +1,56 @@
 {
-  "macros": [
-    "SIG_DFL",
-    "SIG_ERR",
-    "SIG_IGN",
-    "SIGABRT",
-    "SIGFPE",
-    "SIGILL",
-    "SIGINT",
-    "SIGSEGV",
-    "SIGTERM"
-  ],
+  "macros": {
+    "SIG_DFL": {
+      "defined": "7.14.3",
+      "implemented": false
+    },
+    "SIG_ERR": {
+      "defined": "7.14.3",
+      "implemented": false
+    },
+    "SIG_IGN": {
+      "defined": "7.14.3",
+      "implemented": false
+    },
+    "SIGABRT": {
+      "defined": "7.14.3",
+      "implemented": true
+    },
+    "SIGFPE": {
+      "defined": "7.14.3",
+      "implemented": true
+    },
+    "SIGILL": {
+      "defined": "7.14.3",
+      "implemented": true
+    },
+    "SIGINT": {
+      "defined": "7.14.3",
+      "implemented": true
+    },
+    "SIGSEGV": {
+      "defined": "7.14.3",
+      "implemented": true
+    },
+    "SIGTERM": {
+      "defined": "7.14.3",
+      "implemented": true
+    }
+  },
   "functions": {
+    "signal": {
+      "defined": "7.14.1.1"
+    },
+    "raise": {
+      "defined": "7.14.2.1"
+    },
----------------
Flandini wrote:

> I guess a lot of bloviating, but all that to ask what is your reasoning here for moving signal+raise and do we need to change the current sort here in this PR?

I have no strong opinions on the orderings. Based on the previous files, I've been keeping the json files in order of occurrence in the C standard for ease of auditing alongside the standard. This is why I bumped signal and raise up, I was going to let the POSIX functions fall after but totally fine with reverting or alphabetically sorting. `docgen.py` is sorting everything in the `rst` files alphabetically by function/macro name currently. Order in the rst docs seems more, 'how will people use it'?

> Due to 2, these should ultimately be a list, or perhaps another object with distinct fields for C standard section number and hyperlink to POSIX docs (or linux man pages, for other APIs even).

Yeah, I haven't started on listing POSIX hyperlinks yet. I was leaning towards the latter solution with distinct fields and changing `docgen.py` to: change the "Standard" rst column to "C23 Standard", add an optional `POSIX standard#` column (do we need the standard numbers to differentiate C/POSIX standard versions?) that is only added to the generated rst if some row has a POSIX reference in the json.

https://github.com/llvm/llvm-project/pull/89281


More information about the libc-commits mailing list