This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] GCC multilib vs. OS multilib naming (take 2)
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, rth at redhat dot com
- Date: 04 Oct 2002 06:41:49 -0300
- Subject: Re: [PATCH] GCC multilib vs. OS multilib naming (take 2)
- Organization: GCC Team, Red Hat
- References: <20021003172638.S3451@sunsite.ms.mff.cuni.cz>
On Oct 3, 2002, Jakub Jelinek <jakub@redhat.com> wrote:
> @@ -3329,7 +3369,7 @@ process_command (argc, argv)
> else
> nstore[endp - startp] = 0;
> add_prefix (&startfile_prefixes, nstore, NULL,
> - PREFIX_PRIORITY_LAST, 0, NULL);
> + PREFIX_PRIORITY_LAST, 0, NULL, 1);
> if (*endp == 0)
> break;
> endp = startp = endp + 1;
> @@ -3362,7 +3402,7 @@ process_command (argc, argv)
> else
> nstore[endp - startp] = 0;
> add_prefix (&startfile_prefixes, nstore, NULL,
> - PREFIX_PRIORITY_LAST, 0, NULL);
> + PREFIX_PRIORITY_LAST, 0, NULL, 1);
> if (*endp == 0)
> break;
> endp = startp = endp + 1;
Should LIBRARY_PATH and LPATH really follow multilib_os? I have mixed
feelings about it, and I'm more inclined to NOT enable it.
> + char *new_multilib_os_dir = xmalloc (end - q);
> + strncpy (new_multilib_os_dir, q + 1, end - q - 1);
> + new_multilib_os_dir[end - q] = '\0';
Oops. This writes one past the end of the alloced area, and fails to
NUL-terminate the string at the right place. Make it:
new_multilib_os_dir[end - q - 1] = '\0';
^^^^
I suggest replacing the strncpy with memcpy, since you know the exact
the string length anyway.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer