2013-09-01 12:44:07 -07:00
|
|
|
// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2013-10-02 22:06:03 -07:00
|
|
|
/*!
|
|
|
|
|
|
|
|
Cross-platform path support
|
|
|
|
|
|
|
|
This module implements support for two flavors of paths. `PosixPath` represents
|
|
|
|
a path on any unix-like system, whereas `WindowsPath` represents a path on
|
|
|
|
Windows. This module also exposes a typedef `Path` which is equal to the
|
|
|
|
appropriate platform-specific path variant.
|
|
|
|
|
|
|
|
Both `PosixPath` and `WindowsPath` implement a trait `GenericPath`, which
|
|
|
|
contains the set of methods that behave the same for both paths. They each also
|
|
|
|
implement some methods that could not be expressed in `GenericPath`, yet behave
|
2013-11-23 11:18:51 +01:00
|
|
|
identically for both path flavors, such as `.components()`.
|
2013-10-02 22:06:03 -07:00
|
|
|
|
|
|
|
The three main design goals of this module are 1) to avoid unnecessary
|
|
|
|
allocation, 2) to behave the same regardless of which flavor of path is being
|
|
|
|
used, and 3) to support paths that cannot be represented in UTF-8 (as Linux has
|
|
|
|
no restriction on paths beyond disallowing NUL).
|
|
|
|
|
|
|
|
## Usage
|
|
|
|
|
|
|
|
Usage of this module is fairly straightforward. Unless writing platform-specific
|
2013-10-07 19:16:58 -07:00
|
|
|
code, `Path` should be used to refer to the platform-native path.
|
2013-10-02 22:06:03 -07:00
|
|
|
|
2013-12-03 19:15:12 -08:00
|
|
|
Creation of a path is typically done with either `Path::new(some_str)` or
|
|
|
|
`Path::new(some_vec)`. This path can be modified with `.push()` and
|
2013-10-02 22:06:03 -07:00
|
|
|
`.pop()` (and other setters). The resulting Path can either be passed to another
|
|
|
|
API that expects a path, or can be turned into a &[u8] with `.as_vec()` or a
|
|
|
|
Option<&str> with `.as_str()`. Similarly, attributes of the path can be queried
|
|
|
|
with methods such as `.filename()`. There are also methods that return a new
|
|
|
|
path instead of modifying the receiver, such as `.join()` or `.dir_path()`.
|
|
|
|
|
2013-10-02 22:29:46 -07:00
|
|
|
Paths are always kept in normalized form. This means that creating the path
|
2013-12-03 19:15:12 -08:00
|
|
|
`Path::new("a/b/../c")` will return the path `a/c`. Similarly any attempt
|
2013-10-02 22:29:46 -07:00
|
|
|
to mutate the path will always leave it in normalized form.
|
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
When rendering a path to some form of output, there is a method `.display()`
|
2013-10-02 22:06:03 -07:00
|
|
|
which is compatible with the `format!()` parameter `{}`. This will render the
|
|
|
|
path as a string, replacing all non-utf8 sequences with the Replacement
|
|
|
|
Character (U+FFFD). As such it is not suitable for passing to any API that
|
|
|
|
actually operates on the path; it is only intended for display.
|
|
|
|
|
|
|
|
## Example
|
|
|
|
|
|
|
|
```rust
|
2013-12-03 19:15:12 -08:00
|
|
|
let mut path = Path::new("/tmp/path");
|
2013-12-22 13:31:23 -08:00
|
|
|
println!("path: {}", path.display());
|
2013-10-05 19:49:32 -07:00
|
|
|
path.set_filename("foo");
|
|
|
|
path.push("bar");
|
2013-12-22 13:31:23 -08:00
|
|
|
println!("new path: {}", path.display());
|
|
|
|
println!("path exists: {}", path.exists());
|
2013-10-02 22:06:03 -07:00
|
|
|
```
|
|
|
|
|
|
|
|
*/
|
2013-09-01 12:44:07 -07:00
|
|
|
|
|
|
|
use container::Container;
|
|
|
|
use c_str::CString;
|
|
|
|
use clone::Clone;
|
2013-10-01 14:03:41 -07:00
|
|
|
use fmt;
|
2013-09-30 17:13:13 -07:00
|
|
|
use iter::Iterator;
|
2013-09-01 12:44:07 -07:00
|
|
|
use option::{Option, None, Some};
|
|
|
|
use str;
|
2014-02-07 19:45:48 -08:00
|
|
|
use str::{MaybeOwned, OwnedStr, Str, StrSlice, from_utf8_lossy};
|
2013-09-01 12:44:07 -07:00
|
|
|
use vec;
|
2014-01-28 23:40:36 +01:00
|
|
|
use vec::{CloneableVector, OwnedCloneableVector, OwnedVector, Vector};
|
2013-09-01 12:44:07 -07:00
|
|
|
use vec::{ImmutableEqVector, ImmutableVector};
|
|
|
|
|
|
|
|
/// Typedef for POSIX file paths.
|
|
|
|
/// See `posix::Path` for more info.
|
2013-09-26 17:10:55 -07:00
|
|
|
pub use PosixPath = self::posix::Path;
|
2013-09-01 12:44:07 -07:00
|
|
|
|
2013-08-27 00:51:08 -07:00
|
|
|
/// Typedef for Windows file paths.
|
|
|
|
/// See `windows::Path` for more info.
|
2013-09-26 17:10:55 -07:00
|
|
|
pub use WindowsPath = self::windows::Path;
|
2013-09-01 12:44:07 -07:00
|
|
|
|
|
|
|
/// Typedef for the platform-native path type
|
|
|
|
#[cfg(unix)]
|
2013-09-26 17:10:55 -07:00
|
|
|
pub use Path = self::posix::Path;
|
2013-08-27 00:51:08 -07:00
|
|
|
/// Typedef for the platform-native path type
|
|
|
|
#[cfg(windows)]
|
2013-09-26 17:10:55 -07:00
|
|
|
pub use Path = self::windows::Path;
|
2013-09-01 12:44:07 -07:00
|
|
|
|
|
|
|
/// Typedef for the platform-native component iterator
|
|
|
|
#[cfg(unix)]
|
2014-01-14 22:32:24 -05:00
|
|
|
pub use Components = self::posix::Components;
|
2013-09-26 17:21:59 -07:00
|
|
|
/// Typedef for the platform-native reverse component iterator
|
|
|
|
#[cfg(unix)]
|
2014-01-14 22:32:24 -05:00
|
|
|
pub use RevComponents = self::posix::RevComponents;
|
2013-09-26 17:10:55 -07:00
|
|
|
/// Typedef for the platform-native component iterator
|
|
|
|
#[cfg(windows)]
|
2014-01-14 22:32:24 -05:00
|
|
|
pub use Components = self::windows::Components;
|
2013-09-26 17:21:59 -07:00
|
|
|
/// Typedef for the platform-native reverse component iterator
|
|
|
|
#[cfg(windows)]
|
2014-01-14 22:32:24 -05:00
|
|
|
pub use RevComponents = self::windows::RevComponents;
|
2013-09-26 17:21:59 -07:00
|
|
|
|
|
|
|
/// Typedef for the platform-native str component iterator
|
|
|
|
#[cfg(unix)]
|
2014-01-14 22:32:24 -05:00
|
|
|
pub use StrComponents = self::posix::StrComponents;
|
2013-09-26 17:21:59 -07:00
|
|
|
/// Typedef for the platform-native reverse str component iterator
|
|
|
|
#[cfg(unix)]
|
2014-01-14 22:32:24 -05:00
|
|
|
pub use RevStrComponents = self::posix::RevStrComponents;
|
2013-09-26 17:21:59 -07:00
|
|
|
/// Typedef for the platform-native str component iterator
|
|
|
|
#[cfg(windows)]
|
2014-01-14 22:32:24 -05:00
|
|
|
pub use StrComponents = self::windows::StrComponents;
|
2013-09-26 17:21:59 -07:00
|
|
|
/// Typedef for the platform-native reverse str component iterator
|
|
|
|
#[cfg(windows)]
|
2014-01-14 22:32:24 -05:00
|
|
|
pub use RevStrComponents = self::windows::RevStrComponents;
|
2013-09-26 17:10:55 -07:00
|
|
|
|
2014-01-18 09:17:44 -08:00
|
|
|
/// Alias for the platform-native separator character.
|
|
|
|
#[cfg(unix)]
|
|
|
|
pub use SEP = self::posix::SEP;
|
2014-01-20 07:42:28 +09:00
|
|
|
/// Alias for the platform-native separator character.
|
2014-01-18 09:17:44 -08:00
|
|
|
#[cfg(windows)]
|
|
|
|
pub use SEP = self::windows::SEP;
|
|
|
|
|
2014-01-20 07:42:28 +09:00
|
|
|
/// Alias for the platform-native separator byte.
|
2014-01-18 09:17:44 -08:00
|
|
|
#[cfg(unix)]
|
|
|
|
pub use SEP_BYTE = self::posix::SEP_BYTE;
|
|
|
|
/// Alias for the platform-native separator byte.
|
|
|
|
#[cfg(windows)]
|
|
|
|
pub use SEP_BYTE = self::windows::SEP_BYTE;
|
|
|
|
|
2013-10-07 19:16:58 -07:00
|
|
|
/// Typedef for the platform-native separator char func
|
|
|
|
#[cfg(unix)]
|
|
|
|
pub use is_sep = self::posix::is_sep;
|
|
|
|
/// Typedef for the platform-native separator char func
|
|
|
|
#[cfg(windows)]
|
|
|
|
pub use is_sep = self::windows::is_sep;
|
|
|
|
/// Typedef for the platform-native separator byte func
|
|
|
|
#[cfg(unix)]
|
|
|
|
pub use is_sep_byte = self::posix::is_sep_byte;
|
|
|
|
/// Typedef for the platform-native separator byte func
|
|
|
|
#[cfg(windows)]
|
|
|
|
pub use is_sep_byte = self::windows::is_sep_byte;
|
|
|
|
|
2013-09-26 17:10:55 -07:00
|
|
|
pub mod posix;
|
|
|
|
pub mod windows;
|
2013-09-01 12:44:07 -07:00
|
|
|
|
|
|
|
/// A trait that represents the generic operations available on paths
|
|
|
|
pub trait GenericPath: Clone + GenericPathUnsafe {
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Creates a new Path from a byte vector or string.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// The resulting Path will always be normalized.
|
|
|
|
///
|
|
|
|
/// # Failure
|
|
|
|
///
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
/// Fails the task if the path contains a NUL.
|
2013-08-27 00:51:08 -07:00
|
|
|
///
|
|
|
|
/// See individual Path impls for additional restrictions.
|
2013-09-01 12:44:07 -07:00
|
|
|
#[inline]
|
2013-12-03 19:15:12 -08:00
|
|
|
fn new<T: BytesContainer>(path: T) -> Self {
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
assert!(!contains_nul(path.container_as_bytes()));
|
|
|
|
unsafe { GenericPathUnsafe::new_unchecked(path) }
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Creates a new Path from a byte vector or string, if possible.
|
2013-09-26 00:54:30 -07:00
|
|
|
/// The resulting Path will always be normalized.
|
|
|
|
#[inline]
|
2013-12-03 19:15:12 -08:00
|
|
|
fn new_opt<T: BytesContainer>(path: T) -> Option<Self> {
|
2013-10-05 19:49:32 -07:00
|
|
|
if contains_nul(path.container_as_bytes()) {
|
2013-09-26 00:54:30 -07:00
|
|
|
None
|
|
|
|
} else {
|
2013-12-03 19:15:12 -08:00
|
|
|
Some(unsafe { GenericPathUnsafe::new_unchecked(path) })
|
2013-09-26 00:54:30 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-01 12:44:07 -07:00
|
|
|
/// Returns the path as a string, if possible.
|
|
|
|
/// If the path is not representable in utf-8, this returns None.
|
|
|
|
#[inline]
|
|
|
|
fn as_str<'a>(&'a self) -> Option<&'a str> {
|
2013-12-23 17:30:49 +01:00
|
|
|
str::from_utf8(self.as_vec())
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns the path as a byte vector
|
|
|
|
fn as_vec<'a>(&'a self) -> &'a [u8];
|
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Converts the Path into an owned byte vector
|
|
|
|
fn into_vec(self) -> ~[u8];
|
|
|
|
|
2014-01-30 00:46:37 +11:00
|
|
|
/// Returns an object that implements `Show` for printing paths
|
2013-10-01 14:03:41 -07:00
|
|
|
///
|
|
|
|
/// This will print the equivalent of `to_display_str()` when used with a {} format parameter.
|
|
|
|
fn display<'a>(&'a self) -> Display<'a, Self> {
|
2013-10-07 19:16:58 -07:00
|
|
|
Display{ path: self, filename: false }
|
2013-10-01 14:03:41 -07:00
|
|
|
}
|
|
|
|
|
2014-01-30 00:46:37 +11:00
|
|
|
/// Returns an object that implements `Show` for printing filenames
|
2013-10-01 14:03:41 -07:00
|
|
|
///
|
|
|
|
/// This will print the equivalent of `to_filename_display_str()` when used with a {}
|
|
|
|
/// format parameter. If there is no filename, nothing will be printed.
|
2013-10-07 19:16:58 -07:00
|
|
|
fn filename_display<'a>(&'a self) -> Display<'a, Self> {
|
|
|
|
Display{ path: self, filename: true }
|
2013-10-01 14:03:41 -07:00
|
|
|
}
|
|
|
|
|
2013-09-01 12:44:07 -07:00
|
|
|
/// Returns the directory component of `self`, as a byte vector (with no trailing separator).
|
|
|
|
/// If `self` has no directory component, returns ['.'].
|
|
|
|
fn dirname<'a>(&'a self) -> &'a [u8];
|
|
|
|
/// Returns the directory component of `self`, as a string, if possible.
|
|
|
|
/// See `dirname` for details.
|
|
|
|
#[inline]
|
|
|
|
fn dirname_str<'a>(&'a self) -> Option<&'a str> {
|
2013-12-23 17:30:49 +01:00
|
|
|
str::from_utf8(self.dirname())
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
/// Returns the file component of `self`, as a byte vector.
|
2013-09-26 17:21:59 -07:00
|
|
|
/// If `self` represents the root of the file hierarchy, returns None.
|
|
|
|
/// If `self` is "." or "..", returns None.
|
|
|
|
fn filename<'a>(&'a self) -> Option<&'a [u8]>;
|
2013-09-01 12:44:07 -07:00
|
|
|
/// Returns the file component of `self`, as a string, if possible.
|
|
|
|
/// See `filename` for details.
|
|
|
|
#[inline]
|
|
|
|
fn filename_str<'a>(&'a self) -> Option<&'a str> {
|
2013-12-23 17:30:49 +01:00
|
|
|
self.filename().and_then(str::from_utf8)
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
/// Returns the stem of the filename of `self`, as a byte vector.
|
|
|
|
/// The stem is the portion of the filename just before the last '.'.
|
|
|
|
/// If there is no '.', the entire filename is returned.
|
2013-09-26 17:21:59 -07:00
|
|
|
fn filestem<'a>(&'a self) -> Option<&'a [u8]> {
|
|
|
|
match self.filename() {
|
|
|
|
None => None,
|
|
|
|
Some(name) => Some({
|
|
|
|
let dot = '.' as u8;
|
|
|
|
match name.rposition_elem(&dot) {
|
|
|
|
None | Some(0) => name,
|
|
|
|
Some(1) if name == bytes!("..") => name,
|
|
|
|
Some(pos) => name.slice_to(pos)
|
|
|
|
}
|
|
|
|
})
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
/// Returns the stem of the filename of `self`, as a string, if possible.
|
|
|
|
/// See `filestem` for details.
|
|
|
|
#[inline]
|
|
|
|
fn filestem_str<'a>(&'a self) -> Option<&'a str> {
|
2013-12-23 17:30:49 +01:00
|
|
|
self.filestem().and_then(str::from_utf8)
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
/// Returns the extension of the filename of `self`, as an optional byte vector.
|
|
|
|
/// The extension is the portion of the filename just after the last '.'.
|
|
|
|
/// If there is no extension, None is returned.
|
|
|
|
/// If the filename ends in '.', the empty vector is returned.
|
|
|
|
fn extension<'a>(&'a self) -> Option<&'a [u8]> {
|
2013-09-26 17:21:59 -07:00
|
|
|
match self.filename() {
|
|
|
|
None => None,
|
|
|
|
Some(name) => {
|
|
|
|
let dot = '.' as u8;
|
|
|
|
match name.rposition_elem(&dot) {
|
|
|
|
None | Some(0) => None,
|
|
|
|
Some(1) if name == bytes!("..") => None,
|
|
|
|
Some(pos) => Some(name.slice_from(pos+1))
|
|
|
|
}
|
|
|
|
}
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
/// Returns the extension of the filename of `self`, as a string, if possible.
|
|
|
|
/// See `extension` for details.
|
|
|
|
#[inline]
|
|
|
|
fn extension_str<'a>(&'a self) -> Option<&'a str> {
|
2013-12-23 17:30:49 +01:00
|
|
|
self.extension().and_then(str::from_utf8)
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Replaces the filename portion of the path with the given byte vector or string.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// If the replacement name is [], this is equivalent to popping the path.
|
|
|
|
///
|
|
|
|
/// # Failure
|
|
|
|
///
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
/// Fails the task if the filename contains a NUL.
|
2013-09-01 12:44:07 -07:00
|
|
|
#[inline]
|
2013-10-05 19:49:32 -07:00
|
|
|
fn set_filename<T: BytesContainer>(&mut self, filename: T) {
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
assert!(!contains_nul(filename.container_as_bytes()));
|
|
|
|
unsafe { self.set_filename_unchecked(filename) }
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Replaces the extension with the given byte vector or string.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// If there is no extension in `self`, this adds one.
|
2013-10-05 19:49:32 -07:00
|
|
|
/// If the argument is [] or "", this removes the extension.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// If `self` has no filename, this is a no-op.
|
|
|
|
///
|
|
|
|
/// # Failure
|
|
|
|
///
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
/// Fails the task if the extension contains a NUL.
|
2013-10-05 19:49:32 -07:00
|
|
|
fn set_extension<T: BytesContainer>(&mut self, extension: T) {
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
assert!(!contains_nul(extension.container_as_bytes()));
|
2013-09-01 12:44:07 -07:00
|
|
|
// borrowck causes problems here too
|
|
|
|
let val = {
|
2013-09-26 17:21:59 -07:00
|
|
|
match self.filename() {
|
|
|
|
None => None,
|
|
|
|
Some(name) => {
|
|
|
|
let dot = '.' as u8;
|
|
|
|
match name.rposition_elem(&dot) {
|
|
|
|
None | Some(0) => {
|
2013-10-05 19:49:32 -07:00
|
|
|
if extension.container_as_bytes().is_empty() {
|
2013-09-26 17:21:59 -07:00
|
|
|
None
|
2013-09-01 12:44:07 -07:00
|
|
|
} else {
|
2013-09-26 17:21:59 -07:00
|
|
|
let mut v;
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
let extension = extension.container_as_bytes();
|
|
|
|
v = vec::with_capacity(name.len() + extension.len() + 1);
|
|
|
|
v.push_all(name);
|
|
|
|
v.push(dot);
|
|
|
|
v.push_all(extension);
|
2013-09-26 17:21:59 -07:00
|
|
|
Some(v)
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
}
|
2013-09-26 17:21:59 -07:00
|
|
|
Some(idx) => {
|
2013-10-05 19:49:32 -07:00
|
|
|
if extension.container_as_bytes().is_empty() {
|
2013-09-26 17:21:59 -07:00
|
|
|
Some(name.slice_to(idx).to_owned())
|
2013-09-01 12:44:07 -07:00
|
|
|
} else {
|
2013-09-26 17:21:59 -07:00
|
|
|
let mut v;
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
let extension = extension.container_as_bytes();
|
|
|
|
v = vec::with_capacity(idx + extension.len() + 1);
|
|
|
|
v.push_all(name.slice_to(idx+1));
|
|
|
|
v.push_all(extension);
|
2013-09-26 17:21:59 -07:00
|
|
|
Some(v)
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2013-09-26 17:21:59 -07:00
|
|
|
}
|
2013-09-01 12:44:07 -07:00
|
|
|
};
|
|
|
|
match val {
|
|
|
|
None => (),
|
|
|
|
Some(v) => unsafe { self.set_filename_unchecked(v) }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Returns a new Path constructed by replacing the filename with the given
|
|
|
|
/// byte vector or string.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// See `set_filename` for details.
|
|
|
|
///
|
|
|
|
/// # Failure
|
|
|
|
///
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
/// Fails the task if the filename contains a NUL.
|
2013-09-01 12:44:07 -07:00
|
|
|
#[inline]
|
2013-10-05 19:49:32 -07:00
|
|
|
fn with_filename<T: BytesContainer>(&self, filename: T) -> Self {
|
2013-09-01 12:44:07 -07:00
|
|
|
let mut p = self.clone();
|
|
|
|
p.set_filename(filename);
|
|
|
|
p
|
|
|
|
}
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Returns a new Path constructed by setting the extension to the given
|
|
|
|
/// byte vector or string.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// See `set_extension` for details.
|
|
|
|
///
|
|
|
|
/// # Failure
|
|
|
|
///
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
/// Fails the task if the extension contains a NUL.
|
2013-09-01 12:44:07 -07:00
|
|
|
#[inline]
|
2013-10-05 19:49:32 -07:00
|
|
|
fn with_extension<T: BytesContainer>(&self, extension: T) -> Self {
|
2013-09-01 12:44:07 -07:00
|
|
|
let mut p = self.clone();
|
|
|
|
p.set_extension(extension);
|
|
|
|
p
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns the directory component of `self`, as a Path.
|
|
|
|
/// If `self` represents the root of the filesystem hierarchy, returns `self`.
|
|
|
|
fn dir_path(&self) -> Self {
|
2013-08-27 00:51:08 -07:00
|
|
|
// self.dirname() returns a NUL-free vector
|
2013-12-03 19:15:12 -08:00
|
|
|
unsafe { GenericPathUnsafe::new_unchecked(self.dirname()) }
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
|
2013-09-26 17:21:59 -07:00
|
|
|
/// Returns a Path that represents the filesystem root that `self` is rooted in.
|
|
|
|
///
|
2014-01-17 23:07:53 -08:00
|
|
|
/// If `self` is not absolute, or vol/cwd-relative in the case of Windows, this returns None.
|
2013-09-26 17:21:59 -07:00
|
|
|
fn root_path(&self) -> Option<Self>;
|
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Pushes a path (as a byte vector or string) onto `self`.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// If the argument represents an absolute path, it replaces `self`.
|
|
|
|
///
|
|
|
|
/// # Failure
|
|
|
|
///
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
/// Fails the task if the path contains a NUL.
|
2013-09-01 12:44:07 -07:00
|
|
|
#[inline]
|
2013-10-05 19:49:32 -07:00
|
|
|
fn push<T: BytesContainer>(&mut self, path: T) {
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
assert!(!contains_nul(path.container_as_bytes()));
|
|
|
|
unsafe { self.push_unchecked(path) }
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Pushes multiple paths (as byte vectors or strings) onto `self`.
|
2013-09-26 17:21:59 -07:00
|
|
|
/// See `push` for details.
|
|
|
|
#[inline]
|
2013-10-05 19:49:32 -07:00
|
|
|
fn push_many<T: BytesContainer>(&mut self, paths: &[T]) {
|
|
|
|
let t: Option<T> = None;
|
|
|
|
if BytesContainer::is_str(t) {
|
|
|
|
for p in paths.iter() {
|
2013-12-23 17:15:53 +01:00
|
|
|
self.push(p.container_as_str().unwrap())
|
2013-10-05 19:49:32 -07:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
for p in paths.iter() {
|
|
|
|
self.push(p.container_as_bytes())
|
|
|
|
}
|
2013-09-26 17:21:59 -07:00
|
|
|
}
|
|
|
|
}
|
2013-10-09 22:05:14 -07:00
|
|
|
/// Removes the last path component from the receiver.
|
|
|
|
/// Returns `true` if the receiver was modified, or `false` if it already
|
|
|
|
/// represented the root of the file hierarchy.
|
|
|
|
fn pop(&mut self) -> bool;
|
2013-09-01 12:44:07 -07:00
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Returns a new Path constructed by joining `self` with the given path
|
|
|
|
/// (as a byte vector or string).
|
2013-09-01 12:44:07 -07:00
|
|
|
/// If the given path is absolute, the new Path will represent just that.
|
|
|
|
///
|
|
|
|
/// # Failure
|
|
|
|
///
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
/// Fails the task if the path contains a NUL.
|
2013-09-01 12:44:07 -07:00
|
|
|
#[inline]
|
2013-10-05 19:49:32 -07:00
|
|
|
fn join<T: BytesContainer>(&self, path: T) -> Self {
|
2013-09-01 12:44:07 -07:00
|
|
|
let mut p = self.clone();
|
|
|
|
p.push(path);
|
|
|
|
p
|
|
|
|
}
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Returns a new Path constructed by joining `self` with the given paths
|
|
|
|
/// (as byte vectors or strings).
|
2013-09-26 17:21:59 -07:00
|
|
|
/// See `join` for details.
|
|
|
|
#[inline]
|
2013-10-05 19:49:32 -07:00
|
|
|
fn join_many<T: BytesContainer>(&self, paths: &[T]) -> Self {
|
2013-09-26 17:21:59 -07:00
|
|
|
let mut p = self.clone();
|
|
|
|
p.push_many(paths);
|
|
|
|
p
|
|
|
|
}
|
2013-09-01 12:44:07 -07:00
|
|
|
|
|
|
|
/// Returns whether `self` represents an absolute path.
|
2013-08-27 00:51:08 -07:00
|
|
|
/// An absolute path is defined as one that, when joined to another path, will
|
|
|
|
/// yield back the same absolute path.
|
2013-09-01 12:44:07 -07:00
|
|
|
fn is_absolute(&self) -> bool;
|
|
|
|
|
2013-09-26 17:21:59 -07:00
|
|
|
/// Returns whether `self` represents a relative path.
|
|
|
|
/// Typically this is the inverse of `is_absolute`.
|
|
|
|
/// But for Windows paths, it also means the path is not volume-relative or
|
|
|
|
/// relative to the current working directory.
|
|
|
|
fn is_relative(&self) -> bool {
|
|
|
|
!self.is_absolute()
|
|
|
|
}
|
|
|
|
|
2013-09-01 12:44:07 -07:00
|
|
|
/// Returns whether `self` is equal to, or is an ancestor of, the given path.
|
|
|
|
/// If both paths are relative, they are compared as though they are relative
|
|
|
|
/// to the same parent path.
|
|
|
|
fn is_ancestor_of(&self, other: &Self) -> bool;
|
|
|
|
|
|
|
|
/// Returns the Path that, were it joined to `base`, would yield `self`.
|
|
|
|
/// If no such path exists, None is returned.
|
|
|
|
/// If `self` is absolute and `base` is relative, or on Windows if both
|
|
|
|
/// paths refer to separate drives, an absolute path is returned.
|
|
|
|
fn path_relative_from(&self, base: &Self) -> Option<Self>;
|
2013-09-26 14:38:26 -07:00
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Returns whether the relative path `child` is a suffix of `self`.
|
|
|
|
fn ends_with_path(&self, child: &Self) -> bool;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A trait that represents something bytes-like (e.g. a &[u8] or a &str)
|
|
|
|
pub trait BytesContainer {
|
|
|
|
/// Returns a &[u8] representing the receiver
|
|
|
|
fn container_as_bytes<'a>(&'a self) -> &'a [u8];
|
|
|
|
/// Consumes the receiver and converts it into ~[u8]
|
|
|
|
#[inline]
|
|
|
|
fn container_into_owned_bytes(self) -> ~[u8] {
|
|
|
|
self.container_as_bytes().to_owned()
|
|
|
|
}
|
|
|
|
/// Returns the receiver interpreted as a utf-8 string, if possible
|
|
|
|
#[inline]
|
2013-12-23 17:15:53 +01:00
|
|
|
fn container_as_str<'a>(&'a self) -> Option<&'a str> {
|
2013-12-23 17:30:49 +01:00
|
|
|
str::from_utf8(self.container_as_bytes())
|
2013-10-05 19:49:32 -07:00
|
|
|
}
|
2013-10-07 19:16:58 -07:00
|
|
|
/// Returns whether .container_as_str() is guaranteed to not fail
|
2013-10-05 19:49:32 -07:00
|
|
|
// FIXME (#8888): Remove unused arg once ::<for T> works
|
|
|
|
#[inline]
|
|
|
|
fn is_str(_: Option<Self>) -> bool { false }
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/// A trait that represents the unsafe operations on GenericPaths
|
|
|
|
pub trait GenericPathUnsafe {
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Creates a new Path without checking for null bytes.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// The resulting Path will always be normalized.
|
2013-12-03 19:15:12 -08:00
|
|
|
unsafe fn new_unchecked<T: BytesContainer>(path: T) -> Self;
|
2013-09-01 12:44:07 -07:00
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Replaces the filename portion of the path without checking for null
|
|
|
|
/// bytes.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// See `set_filename` for details.
|
2013-10-05 19:49:32 -07:00
|
|
|
unsafe fn set_filename_unchecked<T: BytesContainer>(&mut self, filename: T);
|
2013-08-27 00:51:08 -07:00
|
|
|
|
2013-10-05 19:49:32 -07:00
|
|
|
/// Pushes a path onto `self` without checking for null bytes.
|
2013-09-01 12:44:07 -07:00
|
|
|
/// See `push` for details.
|
2013-10-05 19:49:32 -07:00
|
|
|
unsafe fn push_unchecked<T: BytesContainer>(&mut self, path: T);
|
2013-09-01 12:44:07 -07:00
|
|
|
}
|
|
|
|
|
2013-10-01 14:03:41 -07:00
|
|
|
/// Helper struct for printing paths with format!()
|
2013-12-09 23:16:18 -08:00
|
|
|
pub struct Display<'a, P> {
|
|
|
|
priv path: &'a P,
|
2013-10-07 19:16:58 -07:00
|
|
|
priv filename: bool
|
2013-10-01 14:03:41 -07:00
|
|
|
}
|
|
|
|
|
2014-01-30 00:46:37 +11:00
|
|
|
impl<'a, P: GenericPath> fmt::Show for Display<'a, P> {
|
2014-02-05 23:55:13 +11:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
|
2014-02-07 19:45:48 -08:00
|
|
|
self.as_maybe_owned().as_slice().fmt(f)
|
2013-10-01 14:03:41 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-09 23:16:18 -08:00
|
|
|
impl<'a, P: GenericPath> Display<'a, P> {
|
2014-02-07 19:45:48 -08:00
|
|
|
/// Returns the path as a possibly-owned string.
|
2013-10-06 18:51:49 -07:00
|
|
|
///
|
|
|
|
/// If the path is not UTF-8, invalid sequences will be replaced with the
|
|
|
|
/// unicode replacement char. This involves allocation.
|
|
|
|
#[inline]
|
2014-02-07 19:45:48 -08:00
|
|
|
pub fn as_maybe_owned(&self) -> MaybeOwned<'a> {
|
|
|
|
from_utf8_lossy(if self.filename {
|
|
|
|
match self.path.filename() {
|
|
|
|
None => &[],
|
|
|
|
Some(v) => v
|
2013-10-06 18:51:49 -07:00
|
|
|
}
|
2014-02-07 19:45:48 -08:00
|
|
|
} else {
|
|
|
|
self.path.as_vec()
|
|
|
|
})
|
2013-10-01 14:03:41 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-09 23:16:18 -08:00
|
|
|
impl<'a> BytesContainer for &'a str {
|
2013-10-05 19:49:32 -07:00
|
|
|
#[inline]
|
|
|
|
fn container_as_bytes<'a>(&'a self) -> &'a [u8] {
|
|
|
|
self.as_bytes()
|
|
|
|
}
|
|
|
|
#[inline]
|
2013-12-23 17:15:53 +01:00
|
|
|
fn container_as_str<'a>(&'a self) -> Option<&'a str> {
|
2013-10-05 19:49:32 -07:00
|
|
|
Some(*self)
|
|
|
|
}
|
|
|
|
#[inline]
|
2013-12-09 23:16:18 -08:00
|
|
|
fn is_str(_: Option<&'a str>) -> bool { true }
|
2013-10-05 19:49:32 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
impl BytesContainer for ~str {
|
|
|
|
#[inline]
|
|
|
|
fn container_as_bytes<'a>(&'a self) -> &'a [u8] {
|
|
|
|
self.as_bytes()
|
|
|
|
}
|
|
|
|
#[inline]
|
|
|
|
fn container_into_owned_bytes(self) -> ~[u8] {
|
|
|
|
self.into_bytes()
|
|
|
|
}
|
|
|
|
#[inline]
|
2013-12-23 17:15:53 +01:00
|
|
|
fn container_as_str<'a>(&'a self) -> Option<&'a str> {
|
2013-10-05 19:49:32 -07:00
|
|
|
Some(self.as_slice())
|
|
|
|
}
|
|
|
|
#[inline]
|
|
|
|
fn is_str(_: Option<~str>) -> bool { true }
|
|
|
|
}
|
|
|
|
|
2013-12-09 23:16:18 -08:00
|
|
|
impl<'a> BytesContainer for &'a [u8] {
|
2013-10-05 19:49:32 -07:00
|
|
|
#[inline]
|
|
|
|
fn container_as_bytes<'a>(&'a self) -> &'a [u8] {
|
|
|
|
*self
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl BytesContainer for ~[u8] {
|
|
|
|
#[inline]
|
|
|
|
fn container_as_bytes<'a>(&'a self) -> &'a [u8] {
|
|
|
|
self.as_slice()
|
|
|
|
}
|
|
|
|
#[inline]
|
|
|
|
fn container_into_owned_bytes(self) -> ~[u8] {
|
|
|
|
self
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-07 19:16:58 -07:00
|
|
|
impl BytesContainer for CString {
|
|
|
|
#[inline]
|
|
|
|
fn container_as_bytes<'a>(&'a self) -> &'a [u8] {
|
2014-02-14 15:42:35 -08:00
|
|
|
self.as_bytes_no_nul()
|
2013-10-07 19:16:58 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-07 15:46:25 -08:00
|
|
|
impl<'a> BytesContainer for str::MaybeOwned<'a> {
|
|
|
|
#[inline]
|
|
|
|
fn container_as_bytes<'b>(&'b self) -> &'b [u8] {
|
|
|
|
self.as_slice().as_bytes()
|
|
|
|
}
|
|
|
|
#[inline]
|
|
|
|
fn container_into_owned_bytes(self) -> ~[u8] {
|
|
|
|
self.into_owned().into_bytes()
|
|
|
|
}
|
|
|
|
#[inline]
|
|
|
|
fn container_as_str<'b>(&'b self) -> Option<&'b str> {
|
|
|
|
Some(self.as_slice())
|
|
|
|
}
|
|
|
|
#[inline]
|
|
|
|
fn is_str(_: Option<str::MaybeOwned>) -> bool { true }
|
|
|
|
}
|
|
|
|
|
2013-09-01 12:44:07 -07:00
|
|
|
#[inline(always)]
|
|
|
|
fn contains_nul(v: &[u8]) -> bool {
|
|
|
|
v.iter().any(|&x| x == 0)
|
|
|
|
}
|
2013-09-26 14:24:06 -07:00
|
|
|
|
2013-09-26 17:21:59 -07:00
|
|
|
#[cfg(test)]
|
|
|
|
mod tests {
|
2014-01-06 22:33:37 -08:00
|
|
|
use prelude::*;
|
2013-09-26 17:21:59 -07:00
|
|
|
use super::{GenericPath, PosixPath, WindowsPath};
|
|
|
|
use c_str::ToCStr;
|
|
|
|
|
|
|
|
#[test]
|
2013-10-07 19:16:58 -07:00
|
|
|
fn test_cstring() {
|
2013-09-26 17:21:59 -07:00
|
|
|
let input = "/foo/bar/baz";
|
2013-12-03 19:15:12 -08:00
|
|
|
let path: PosixPath = PosixPath::new(input.to_c_str());
|
2013-09-26 17:21:59 -07:00
|
|
|
assert_eq!(path.as_vec(), input.as_bytes());
|
|
|
|
|
2013-10-22 18:25:07 -07:00
|
|
|
let input = r"\foo\bar\baz";
|
2013-12-03 19:15:12 -08:00
|
|
|
let path: WindowsPath = WindowsPath::new(input.to_c_str());
|
2013-10-01 23:41:59 -07:00
|
|
|
assert_eq!(path.as_str().unwrap(), input.as_slice());
|
2013-09-26 17:21:59 -07:00
|
|
|
}
|
|
|
|
}
|