Skip to content

Code quality issues #1

@lordmauve

Description

@lordmauve

This review of the C code was offered by Christos:

  • you should either check strdup or use stack storage (I would use stack storage, since you can only be PATH_MAX).
  • you made it unnecessarily linux-specific by including linux only headers. There is limits.h for example.
  • sysexits.h is unused and obsolete (use stdlib.h EXIT_SUCCESS/EXIT_FAILURE)
  • use err/warn{,x} from <err.h> instead of fprintf to report errors (that way you don't need to hard-code the program name.
  • don't use memmove unless the memory can be overlapping; here it never is (memcpy is good enough)
  • argument order should be (char *dst, size_t dstsize, const char *src); this is the convention (see snprintf etc).
  • _ var names are reserved by the implementation
  • follow_link could be made static.
  • ARG_MAX is not the length of an individual argument; it is the combined size of the argv + envp space that can be passed to exec. It is usually pretty big and for you it is a lot bigger since it is * sizeof (char *). But you really never have to worry about that because the shebang length is 128 on linux and typically less than that (the kernel will never pass you more), so don't use ARG_MAX (now you don't need limits.h) just use something like 128 for the number of arguments and it will be good enough.
  • you should make joinpath always set errno so you can use err() and print a sensible error like you do in follow_link.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions