On 9/18/24 15:54, Steffen Nurpmeso wrote:
Hello.
Stephen J. Kiernan wrote in
<202409181954.48ijsbgl047...@gitrepo.freebsd.org>:
...
|URL: https://cgit.FreeBSD.org/src/commit/?id=ce9c3abf69c2044c1aab0aa62e4\
|a73f8eb13d787
|
|commit ce9c3abf69c2044c1aab0aa62e4a73f8eb13d787
|Author: Stephen J. Kiernan <ste...@freebsd.org>
|AuthorDate: 2024-09-18 19:49:46 +0000
|Commit: Stephen J. Kiernan <ste...@freebsd.org>
|CommitDate: 2024-09-18 19:49:46 +0000
|
| config: Search include paths for files to be read (options, files)
|
| This is useful for downstream consumers to add their own kernel config
| files in another directory other than the default ones.
|
| Obtained from: Juniper Networks, Inc.
| Differential Revision: https://reviews.freebsd.org/D44538
...
[... snip ...]
|+ free(fnamebuf);
|+ }
|+ }
|+ }
| if (fp == NULL)
| err(1, "%s", fname);
Having said that. Why is that file marked .cc aka C++?
This is so pure basic C Mr. Somers surely gets goose pimples, and
then comes back complaining that a memory safe language would not
have had this problem. File pointer, asprintf (horrors!), lots of
char pointers, SLIST_FOREACH() not some object encapsulating
possible difficulties, and what not.
In short -- this changeset is surely meant to buy Rust some
buffalo nickels, and whereas some maybe smile, the Rust gets
armored steel .. and in the end we have to use this merde (imho).
Because it uses a C++ feature. Notably, I had no interest in
implementing the equivalent of std::unordered_map when I can quickly
convert it to .cc and expect it to work.
Thanks,
Kyle Evans
