> On Jan. 9, 2016, 12:42 a.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/internal/windows/dirent.hpp,
> >  line 204
> > <https://reviews.apache.org/r/39019/diff/10/?file=1175210#file1175210line204>
> >
> >     why assert vs. false with errno?
> 
> Alex Clemmer wrote:
>     Actually, I changed my mind about the stuff I wrote about `assert` above, 
> which I clicked "publish" on a couple minutes ago.
>     
>     I tend to think of `errno` (loosely) as communicating an error performing 
> some action at an API level. For example, if you pass a nonexistant directory 
> to `opendir` then `errno` will be populated to indicate that. But, in this 
> case, if the `DIR*` passed to `_openDirStream` is `NULL`, because 
> `_openDirStream` does not know how to communicate to the caller of `opendir` 
> what went wrong. Did we run out of memory, which caused the `DIR*` to be 
> `NULL`? Did we overwrite something somewhere? We don't know. This is in 
> contrast to the case where we try to find the first file in the directory 
> stream. In this case, `_openDirStream` is the _only_ function that can 
> populate `errno`, because it is the only function that knows what went wrong! 
> Therefore, we populate `errno` in that case, and only that case.
>     
>     So, in this case, I think it's better to just `assert` rather than set 
> `errno`: because, if even if we do set `errno` to indicate that `NULL` is 
> unacceptable, the user won't know what the problem is, and can't change their 
> input accordingly. In contrast, when you `assert`, it becomes very obvious 
> that there is a bug in internal code, which is infinitely preferable IMHO.
>     
>     What do you think?

Following up, we've agreed that it's acceptable to do this in an internal API, 
but leading underscores is not a "good enough" solution. So, in this next 
revision, we will move these internal APIs to the `internal` namespace.


- Alex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39019/#review113576
-----------------------------------------------------------


On Jan. 11, 2016, 10:03 p.m., Alex Clemmer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39019/
> -----------------------------------------------------------
> 
> (Updated Jan. 11, 2016, 10:03 p.m.)
> 
> 
> Review request for mesos, Alex Naparu, Daniel Pravat, Artem Harutyunyan, 
> Joris Van Remoortere, and Joseph Wu.
> 
> 
> Bugs: MESOS-3441
>     https://issues.apache.org/jira/browse/MESOS-3441
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Windows: Added dirent compat code for non-Unix systems.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/Makefile.am 
> b2dea9b93adfa3ea0415a0b5c81a369dd29b6cfe 
>   
> 3rdparty/libprocess/3rdparty/stout/include/stout/internal/windows/dirent.hpp 
> PRE-CREATION 
>   3rdparty/libprocess/3rdparty/stout/include/stout/windows.hpp 
> d46e262e0fd1c2de36f3bf19d8bd693c23bf58cd 
> 
> Diff: https://reviews.apache.org/r/39019/diff/
> 
> 
> Testing
> -------
> 
> `make check` from autotools on Ubuntu 15.
> `make check` from CMake on OS X 10.10.
> Ran `check` project in VS on Windows 10.
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Reply via email to