Strings always require an extra memory buffer, why?

[itpp14]

Hello,

I am trying to add some functionality to this project:
https://github.com/openresty/lua-upstream-nginx-module
under this https://github.com/openresty/lua-upstream-nginx-module/pull/9

This latest comment based on;

host.data = (u_char *) "112.168.231.19:80";
for (i = 0; i < peer->name.len; i++) {
    peer->name.data[i] = host.data[i];
}
or more simpler:
peer->name.data = host.data;

States: "Because strings always require an extra memory buffer (and the burden of memory management) while primitive values like booleans and numbers don't."

Which makes sense since a boolean change (down/up) does actually changes a runtime value, however the string replacement shows via '/upstreams' that the value has changed but at runtime it is still using the old value.

So in short it looks like I do need a buffer to change the string value.

My question is why? if 'peer->down' works on a memory fragment where its value resides then why doesn't a 'peer->name.data = host.data' do the same thing? can this be done without a buffer? once you allocate memory and store host.data in to this where do I copy it to?

[ne555]

'data' is a uchar*, a pointer.
look for "shallow copy - deep copy" http://stackoverflow.com/questions/184710/what-is-the-difference-between-a-deep-copy-and-a-shallow-copy (second answer has a diagram)
peer->name.data = host.data; is shallow


By the way "string literals" are const
you cannot do host.data[0] = '2'

Also, you shouldn't deallocate 'host.data' as it was not dynamically allocated (wonder how that especial case is handled)


> can this be done without a buffer?
not sure what you are trying to say.

[itpp14]

Tnx for that stack article, to some extend I understand the difference but it makes no sense to me when this:
'peer->down = true' works
while
'peer->name.data = host.data' doesn't work

'/upstreams' obtains a copy of the runtime values, after a 'peer->down' you see the state of a peer changed to down and also the program is not using the peer anymore(because its set as down), however when you do a 'peer->name.data = host.data' to change a peer's address the '/upstreams' show the new address (so something somewhere does what it suppose to do) but the program is still using the peer's old address which indicates where the change occurred is not the same area where peer->down lives.

Lets try to illustrate what I'm looking after;
a = 1
b = '12345'
peer->down = a
peer->name = b

memory: array: 1,0,1,'named','12345',0,0,1
when a is changed I am assuming array value 2 is set to true (1), which seems to be the case because it works.
when b is changed I am assuming array value 4 is set, this is happening but somehow in a copy of the array somewhere because /upstreams is showing it is changed but the program is not doing anything with this new value, the question is why? how does this relate between shallow and deep copy? (which are both still a copy and have no pointer back to where the original value is kept)

Or in a different matter, if peer->down points to the real runtime location how can I get the same with peer->name(.data)?

Something like 'peer->name = host' or '&peer->name = host' ?

[ne555]

http://blog.codinghorror.com/rubber-duck-problem-solving/

> '/upstreams' obtains a copy
¿who?
¿what's "/upstreams"?

> '/upstreams' show the new address but the program is still using the peer's old address
¿how are you checking that?


Try to create a minimal example.


> Lets try to illustrate what I'm looking after;
Please do, I don't understand what you are trying to show there.

> when a is changed I am assuming array value 2 is set to true
¿why? ¿what's that memory dump? ¿what are those other values? ¿what part is 'a', 'b', 'peer'?

[itpp14]

I'll assemble a package and get back to you with a test suite.

[itpp14]

And while I was doing that I realized a few things, a minimal example compilable and with Lua code and config example all working (except the ip thing) can be found following this link https://github.com/openresty/lua-upstream-nginx-module/issues/10

My guess those ip values are in a cache somewhere...