=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>, =?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>, =?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>, =?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>, =?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com> Message-ID: In-Reply-To: <llvm.org/llvm/llvm-project/pull/76...@github.com>
================ @@ -1385,14 +1385,16 @@ Improvements ^^^^^^^^^^^^ - Improved the ``unix.StdCLibraryFunctions`` checker by modeling more - functions like ``send``, ``recv``, ``readlink``, ``fflush``, ``mkdtemp``, - ``getcwd`` and ``errno`` behavior. + functions like ``send``, ``recv``, ``readlink``, ``fgetc``, ``fgets``, + ``fputc``, ``fputs``, ``fflush``, ``mkdtemp``,``getcwd`` and + ``errno`` behavior. ---------------- steakhal wrote: Given that `release/18.x` has branched off, I think we are better off not touching the release notes. I advocate for only keeping the release notes up-to-date right before branching for a release (basically what we did), but not touching it for the rest of the time. By nature, release notes are frequently touched, and even if our stuff does not change, the diff context may. This can cause inconveniences for downstream users for reverting or backporting patches. And they don't really bring a lot of benefit, as I'd need to go over the changes prior a release anyways - just to be sure all important changes were mentioned. On that note, I kinda regret that I wanted a full list of PRs for the `StdCLibraryFunctions` checker, as it got bloated quite a bit over the last month. I wasn't expecting that much of a motion in this area TBH. https://github.com/llvm/llvm-project/pull/76979 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
