Boost logo

Boost :

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2022-08-23 23:36:34

On Tue, Aug 23, 2022 at 4:23 PM Gavin Lambert via Boost
<boost_at_[hidden]> wrote:
> > url_base& url_base::set_port( string_view ); // throws
> > result<void> url_base::try_set_port( string_view ); // returns result
> >
> Why is it a string at all? Shouldn't it be exclusively a uint16_t?

Its a good question. Every member function in the reference has a BNF
section which shows the grammar, and a Specification section which
provides a link to the relevant specifications document (RFC3986 in
this case):


The RFC says:

    port = *DIGIT

That means that "80", "443", and "8080" are examples of valid ports.
"65535" is a valid port. But so is "4294967295" or even
"999999999999999999". In fact "0" is a valid port, as well as "00" or
any number of leading zeroes, followed by any number of digits
(including no digits). And the empty string "" is a valid port.
Boost.URL recognizes the distinction between having a port which is
the empty string, and not having a port at all, by providing the
function remove_port() and the function has_port(). Calling
set_port("") is semantically different from calling remove_port(), and
results in a different URL. This is per the RFC grammar:

    authority = [ userinfo "@" ] host [ ":" port ]

Because this library is capable of representing ALL URLs, it is
necessary for the interface to allow the caller to interact with the
port as a string which is valid according to the grammar. But of
course people need to treat it like an integer so we have overloads
for setting the port as a sixteen bit unsigned number, and retrieving
the port as the same.



Boost list run by bdawes at, gregod at, cpdaniel at, john at