9src/cc: fix objs list to use objext, not hardcoded "o"#134
Conversation
The object written by the compiler used objext (.6 for amd64 pcc) but the objs list still held .o, so 6l was handed a nonexistent filename. 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 updates the C compiler wrapper to use the architecture-specific objext variable instead of a hardcoded ".o" extension when generating object file names from source files. A review comment points out a potential inconsistency between the use of objext and the existing ot->o check used to identify object files in the command-line arguments, suggesting that these should be unified to avoid logic errors.
| if(strcmp(suf, "c") == 0) { | ||
| append(&srcs, s); | ||
| append(&objs, changeext(s, "o")); | ||
| append(&objs, changeext(s, objext)); |
There was a problem hiding this comment.
The use of objext here is inconsistent with the check on line 173, which uses ot->o to recognize existing object files. If objext and ot->o are intended to represent the same architecture-specific extension, it would be better to use a single variable consistently. If they can differ, this change might cause files with the objext extension passed on the command line to be ignored by the recognition logic in the else if block, while still allowing .o files which may no longer be appropriate for the target architecture.
2 participants
The object written by the compiler used objext (.6 for amd64 pcc) but the objs list still held .o, so 6l was handed a nonexistent filename.
https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs