Don't rely on path_max
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- c, linux
- 领域
- cli, operating-systems
调研方向
首先定位所有与 realpath(3) 和 readlink(2) 相关的 PATH_MAX 使用位置，然后检查 Windows 的 static inline realpath 别名以及 terminalshell_linux 的 FF_EXE_PATH_LEN。比较 Hurd 和 Linux 上的分配行为，并考虑是否可以用共享 helper 替换分散的条件判断；完成的标准是在不破坏这些平台特定路径的情况下，不再需要 Hurd 的 PATH_MAX hack。
由索引模型根据 Issue 内容生成。
描述
Hi,
Following up to my comment in https://github.com/fastfetch-cli/fastfetch/issues/1895#issuecomment-3206602801 on PATH_MAX.
I would like to get rid of the -DPATH_MAX=4096 hack for hurd.
I had a look where PATH_MAX is used and it is used only for realpath(3) and readlink(2) to allocate a buffer that will be "big enough".
For realpath glibc will allocate a buffer for us with the result when the output is NULL. (this case is not specified by posix). I don't think this is something that other libcs implement though.
The man page for readlink also suggests to not rely on PATH_MAX and suggests to use stat.st_size from lstat and malloc a buffer manually.
The problem with this approach is that while lstat on /proc returns sensible values on hurd e.g. on linux the size is 0 so the PATH_MAX approach is still needed.
Also there are currently at least 2 static inline realpath aliases for windows.
terminalshell_linux has a FF_EXE_PATH_LEN instead.
Before I start to make this work would it make sense to consolidate this into new helpers to not litter #ifdef PATH_MAX everywhere?
- 主要语言
- C
- 星标
- 25k
- 派生
- 928
- 平均合并
- 16 小时 11 分钟
- 30 天内合并 PR
- 21
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
fastfetch-cli/fastfetch 的其他 Issue
-
logo request
难度 2/5 1-3 小时 新手友好度 72/100
fastfetch-cli/fastfetch#2650 ·
维护者通常 1 天内回复
-
[LOGO] Keenetic OS可能已有人在做 @Ivan-Alone 于 8 天前认领。 未关闭logo request
难度 2/5 1-3 小时 新手友好度 72/100
fastfetch-cli/fastfetch#2646 ·
维护者通常 1 天内回复
-
[LOGO] Darkian Linux可能已有人在做 @lordpipon 于 8 天前认领。 未关闭logo request
难度 2/5 1-3 小时 新手友好度 66/100
fastfetch-cli/fastfetch#2644 ·
维护者通常 1 天内回复
-
[LOGO] ArmadaOS可能已有人在做 @Tyagiquamar 于 5 天前认领。 未关闭logo request
难度 2/5 1-3 小时 新手友好度 72/100
fastfetch-cli/fastfetch#2641 ·
维护者通常 1 天内回复
-
[LOGO] OxyohanOS未关闭logo request
难度 2/5 1-3 小时 新手友好度 65/100
fastfetch-cli/fastfetch#2638 ·
维护者通常 1 天内回复
查看 fastfetch-cli/fastfetch 的全部 Issue
相似的 Issue
-
backlog bug
难度 2/5 1-3 小时 新手友好度 75/100
EchoTools/nevr-runtime#653 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
InfiniTimeOrg/InfiniTime#2492 ·
-
难度 2/5 1-3 小时 新手友好度 80/100
维护者通常 1 天内回复
-
system: coco
难度 1/5 1 小时以内 新手友好度 90/100
FujiNetWIFI/fujinet-config#274 ·
维护者通常 1 天内回复
-
base-files: 82_config_generate: regenerate /etc/board.json if 0-bytes / truncated after power cut未关闭
难度 2/5 1-3 小时 新手友好度 72/100
openwrt/openwrt#25940 · 5 条评论 ·
维护者通常 1 天内回复