Invalid httpport argument passed from traffic_manager to traffic_server

I'm seeing a weird issue with invalid httpport option being passed from traffic_manager to traffic_server process. My ps output look a bit like this (I'm only running traffic_manager and not traffic_cop)

ats      27565  0.0  0.2 374712 16176 pts/0    Sl   14:32   0:00 /trafficserver/bin/traffic_manager
ats      27574  1.7  0.8 569440 52036 pts/0    Sl   14:32   0:03 /trafficserver/bin/traffic_server -M --httpport ip-in=[10.50.156.251]:443:fd=15:ssl,8443:fd=16:ssl?ݻ?

Notice some garbage characters at the end of traffic_server's httpport arg. That also reflects in the log as follows.

WARNING: Invalid option 'ssl�ݻ' in port configuration '8443:fd=16:ssl�ݻ'

My server_ports in records.config is as follows.

CONFIG proxy.config.http.server_ports STRING ssl:443:ip-in=[10.50.156.251],ssl:8443

After spending some time looking at the code in LocalManager::startProxy (LocalManager.cc:1037), I believe the char Vec namely real_proxy_options is not being null-terminated despite the attempt of doing so in line 1037.

    // NUL-terminate for the benefit of strtok and printf.
    real_proxy_options.append('\0');

This is, I think, because of the Vec's implementation of appending from another Vec which explicitly check for if an element is 0 then don't append that element (line 352 in lib/ts/Vec.h).

template <class C, class A, int S> inline void
Vec<C,A,S>::append(const Vec<C> &vv)  {
  for (C *c = vv.v; c < vv.v + vv.n; c++)
    if (*c != 0)
      add(*c);
}

I have no idea why the implementation of Vec is that way but I would think it's probably safer not messing around with a container class that has been used in many other places. So, my suggestion would be something like this in LocalManager.

    // NUL-terminate for the benefit of strtok and printf.
    real_proxy_options.append("", 1);

Any thought would be very welcome.