From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D0D1E3858439; Mon, 24 Oct 2022 15:22:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0D1E3858439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1666624938; bh=OddaiZ9C7G65PewBLbpT40BRfZis64ppK+GmegHY/1o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SPvAhOG0nlcfJQm05qA+y74FrPfDOdUNnTiNAgkjJMjO8mpszedhAvtcmvGVaOPmM oFzTmTaE/HrAZVtC3u579AgNGLzsyP57hDZQrA8zL2CxCRIaz7OCtF8spawzqU8/E6 JDNmLkFNMLVm8wbLi0u6WEGRI9eoVM8Ltr5g9l5w= From: "costas.argyris at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug driver/107007] libiberty's win32_spawn error handling is poor Date: Mon, 24 Oct 2022 15:22:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: driver X-Bugzilla-Version: 12.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: costas.argyris at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107007 Costas Argyris changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |costas.argyris at gmail do= t com --- Comment #1 from Costas Argyris --- A potential improvement in the win32_spawn function could be to check the length of cmdline https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L625 before passing it to CreateProcess https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L630 because we know from https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-pr= ocessthreadsapi-createprocessa#parameters that the second argument cannot be more than 32,767 characters. So if we can check that before even making the call to CreateProcess, why bother doing a call that we know will fail? Perhaps the check could be done inside the argv_to_cmdline function itself.= =20=20=20 This function mentions the 32k limit in its comments https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L350 but doesn't actually consider it in the code. Looks like the length has = been decided by the time we reach https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L385 in the cmdline_len variable, so it should be just a simple numerical check = that this value is less than or equal to 32,767 before doing the memory allocati= on.=20 If greater, it could just return NULL without allocating any memory and t= he (single) caller at https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L625 already deals with NULL.=