Bug 50028 – Simplify directoryName in FileSystemWin.cpp

• Component: Platform
• Status: RESOLVED FIXED

[Patrick R. Gansterer]

see patch

[Patrick R. Gansterer]

Created attachment 74765 [details]
Patch

[Build Bot]

Attachment 74765 [details] did not build on win:
Build output: http://queues.webkit.org/results/6296043

[Patrick R. Gansterer]

Created attachment 74772 [details]
Patch

[Adam Roben (:aroben)]

Comment on attachment 74772 [details]
Patch

Seems like eventually we should switch to using ::PathRemoveFileSpecW.

[Patrick R. Gansterer]

(In reply to comment #4)
> (From update of attachment 74772 [details])
> Seems like eventually we should switch to using ::PathRemoveFileSpecW.
PathRemoveFileSpecW wants to work in a buffer. So we would need to copy the path first into the buffer and then out of if. I like the current version more, but I can change if you like the other one more.

[Adam Roben (:aroben)]

(In reply to comment #5)
> (In reply to comment #4)
> > (From update of attachment 74772 [details] [details])
> > Seems like eventually we should switch to using ::PathRemoveFileSpecW.
> PathRemoveFileSpecW wants to work in a buffer. So we would need to copy the path first into the buffer and then out of if. I like the current version more, but I can change if you like the other one more.

I think if we used StringBuffer or Vector<UniChar> we could get away with only a single copy, which is probably even better than the current implementation. But making this change I think would warrant a separate patch.

[Patrick R. Gansterer]

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (From update of attachment 74772 [details] [details] [details])
> > > Seems like eventually we should switch to using ::PathRemoveFileSpecW.
> > PathRemoveFileSpecW wants to work in a buffer. So we would need to copy the path first into the buffer and then out of if. I like the current version more, but I can change if you like the other one more.
> 
> I think if we used StringBuffer or Vector<UniChar> we could get away with only a single copy, which is probably even better than the current implementation. But making this change I think would warrant a separate patch.
OK, I'll create a new patch in the next days.

[WebKit Commit Bot]

Comment on attachment 74772 [details]
Patch

Rejecting patch 74772 from commit-queue.

Failed to run "['./WebKitTools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=eseidel-cq-sl', 'build', '--no-clean', '--no-update', '--build-style=both']" exit_code: 2
Last 500 characters of output:
g/RenderDataGrid.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2
	CompileC /Projects/CommitQueue/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/RenderLayer.o /Projects/CommitQueue/WebCore/rendering/RenderLayer.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2
	CompileC /Projects/CommitQueue/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/Frame.o /Projects/CommitQueue/WebCore/page/Frame.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2
(6 failures)


Full output: http://queues.webkit.org/results/6387099

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 74772 [details]:

fast/workers/storage/use-same-database-in-page-and-workers.html
inspector/timeline-event-dispatch.html

Please file bugs against the tests.  These tests were authored by [e-mail], [e-mail], and [e-mail].  The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

Comment on attachment 74772 [details]
Patch

Clearing flags on attachment: 74772

Committed r72808: <http://trac.webkit.org/changeset/72808>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.