[Lldb-commits] [PATCH] D17107: [lldb] Unicode support on Win32
Cameron via lldb-commits
lldb-commits at lists.llvm.org
Mon Feb 22 17:42:31 PST 2016
cameron314 added inline comments.
================
Comment at: lldb/trunk/source/Host/common/FileSpec.cpp:1179
@@ +1178,3 @@
+
+ char child_path[PATH_MAX];
+ const int child_path_len = ::snprintf (child_path, sizeof(child_path), "%s\\%s", dir_path, fileName.c_str());
----------------
amccarth wrote:
> cameron314 wrote:
> > amccarth wrote:
> > > cameron314 wrote:
> > > > amccarth wrote:
> > > > > MAX_PATH in Windows. (And someday, we should get rid of these fixed buffers so we can use UNC paths.)
> > > > I absolutely agree re the fixed buffers. I'll try to make this change in all of the functions that can allocate dynamic memory.
> > > >
> > > > `MAX_PATH` is not `PATH_MAX`, though -- `MAX_PATH` is a Win32 constant of 260, whereas `PATH_MAX` is an LLDB constant of 32K. (Actually PATH_MAX is defined in multiple places and was either that or MAX_PATH depending on which header was included, but mostly it was 32K so I changed them all to at least be consistently 32K.)
> > > Ah, I see. I work in another code base where PATH_MAX is synonymous with MAX_PATH, so I was confused.
> > >
> > > Buffers of 32K characters on the stack seem like a bad idea. We need a vector or string or some other container that puts the bulk of the data somewhere other than the stack.
> > Right. There's currently ~110 places in LLDB that allocate buffers of size `PATH_MAX` on the stack. Nearly all of those predate my patch, it seems.
> Right, but this is a new case because you changed it from MAX_PATH (260) to PATH_MAX (32K). I'd rather not introduce more instances like this.
Good point, I'll fix it up :-)
Repository:
rL LLVM
http://reviews.llvm.org/D17107
More information about the lldb-commits
mailing list