2009/6/10 Doug Goldstein <cardoe@xxxxxxxxxx>:
> This patch adds a new function virFindFileInPath() and uses it to find
> where a binary lives in the PATH environment variable. [...]
+/*
+ * Finds a requested file in the PATH env. e.g.:
+ * "kvm-img" will return "/usr/bin/kvm-img"
+ *
+ * You must free the result
+ */
+char *virFindFileInPath(const char *file)
+{
+ char pathenv[PATH_MAX];
+ char *penv = &pathenv; /* this is for glibc 2.10 strsep chnages */
+ char *pathseg;
+ char fullpath[PATH_MAX];
+
+ /* copy PATH env so we can tweak it */
+ strncpy(pathenv, getenv("PATH"), PATH_MAX);
+ pathenv[PATH_MAX - 1] = '\0';
+
+ /* for each path segment, append the file to search for and test for
+ * it. return it if found.
+ */
+ while ((pathseg = strsep(&penv, ":")) != NULL) {
+ snprintf(fullpath, PATH_MAX, "%s/%s", pathseg, file);
+ if (virFileExists(fullpath))
+ return strdup(fullpath);
+ }
+
+ return NULL;
+}
GCC (version 4.3.3 here) warns about "initialization from incompatible
pointer type" at this line:
char *penv = &pathenv; /* this is for glibc 2.10 strsep chnages */
Changing it to
char *penv = pathenv; /* this is for glibc 2.10 strsep chnages */
fixes the warning.
At first I was surprised that the first version with & works and gives
correct results, then I checked that actual values that are assigned
to char *penv and it's the same in both cases. But the point is: the
additional & triggers a warning (breaks compilation with
--enable-compile-warnings=error) and removing it doesn't change the
behavior.
PS: What's this comment about changes in glibc 2.10 to strsep()
referring to? I looked at the changelog but couldn't find any recent
changes to strsep().
Regards,
Matthias
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list