From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 517803858D1E; Mon, 20 Feb 2023 21:39:05 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 517803858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1676929145;
	bh=j8xTQy3TdRSmvcU/ZuDhyHvNAX/GRFnX01vhG3+P0TE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=wa+LmQOU6dEdPno1LG/9DHsDNgsbxP/9YQ604UkWbL7VKWVoNLZoIvQB9RyB/9YSB
	 HJ6loNVo80Rli6a5Mr/CXjV71SCYzvlO91vHwKyuDBTCrJ0ChWUGp5aWY8XjVpHF1x
	 u6EU4heZTF1wctLOibK0t1Lxu1KwbkxksLeAoqCg=
From: "costas.argyris at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/108865] gcc on Windows fails with Unicode path to source
 file
Date: Mon, 20 Feb 2023 21:39:05 +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: unknown
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: 
Message-ID: <bug-108865-4-1ypZVvSZk2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108865-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108865-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108865

--- Comment #2 from Costas Argyris <costas.argyris at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> Utf8 is the best generic solution really.
> Using wmain is not very portable and the rest of gcc's sources can't use
> wchar_t as that would break unix/Linux handling.

Yes, on that, I was thinking to only use wchar_t in wmain just to get the
arguments properly (not destroyed), and immediately convert to UTF-8 char
arrays to pass to the rest of the program (starting with the call to
driver.main which main wraps).    That way, all sources would stay the same
working with char arrays, only this time it would be UTF-8 char arrays that
properly carry the Unicode args.    This would allow only selected parts of=
 the
Windows-specific code (possibly only in libiberty/pex-win32.c) to opt-in for
the necessary conversion back to wchar_t UTF-16 arrays in order to call the
Unicode versions of Win32 APIs like CreateProcessW etc., and get end-to-end
Unicode support on Windows.=