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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
