Claude/upgrade ape c library mm z gd#133
Conversation
The native 9front pcc script ignores -g and produces 6.out (no -o passed to 6l). This rc script shadows it via the apexp-sh bind mount, delegating to /$objtype/bin/ape/cc which is the APExp cc wrapper (9src/cc.c) with full -g / dwtypes / dw2elf pipeline support. https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs
- putenv("_DWTYPES=1") → putenv("_DWTYPES","1"): Plan9 libc uses 2-arg form
- unsetenv("_DWTYPES") → putenv("_DWTYPES",""): no unsetenv in Plan9 libc
- argv[0]-based object extension: cc→.o (configure compat), pcc→.$O (Plan9 native)
- mkfile: install pcc as a copy of cc so the compiled binary shadows native pcc
- Remove rc/bin/ape/pcc script (superseded by the compiled binary)
https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a dual-mode behavior for the cc driver, allowing it to use either the standard .o object extension for compatibility or the architecture-native extension when invoked as pcc. It also updates environment variable management and adds build rules for the pcc binary. Feedback indicates that the method for unsetting the _DWTYPES environment variable is incorrect for the target environment and that the logic for determining the executable name from argv[0] is fragile when paths are included.
| } | ||
| if(gflag) | ||
| unsetenv("_DWTYPES"); | ||
| putenv("_DWTYPES", ""); |
There was a problem hiding this comment.
In the Plan 9 environment (which the 2-argument putenv call implies), putenv(name, "") sets the environment variable to an empty string rather than removing it. Since getenv() returns a non-NULL pointer for empty strings, any subsequent code (such as the linker called on line 214) that checks for the existence of _DWTYPES will still see it as set. To properly unset the variable so that getenv returns NULL, you should pass (char*)0 (or nil) as the second argument.
putenv("_DWTYPES", (char*)0);| ot = findoty(); | ||
| oname = "a.out"; | ||
| /* cc produces .o (for configure compat); pcc uses arch-native .$O */ | ||
| objext = (strcmp(argv[0], "cc") == 0) ? "o" : ot->o; |
There was a problem hiding this comment.
The check strcmp(argv[0], "cc") is fragile because argv[0] may contain the full or relative path to the executable (e.g., /bin/cc or ./cc). In such cases, the condition will fail, and the driver will use the architecture-native extension instead of .o, which defeats the purpose of the "configure compat" mode when the tool is invoked via its path. It is more robust to check the base name of the command (e.g., using strrchr(argv[0], '/')).
2 participants
No description provided.