Claudio Valderrama C. wrote:

>If I have an embedded FB, I don't want to open sockets unnecessarily.
>IB and FB are so loaded with buffer overruns that creating more avenues for
>them to be exploited through unnecesary sockets waiting for connections
>seems silly for me. Some people care about security. Others don't. Other
>don't understand. Others don't get the idea that security is integral part
>of a design, not a varnish at the end of the programming stage.
>Just give the person that ships a program with embedded FB the option to not
>have open sockets exposed. I think this was Roman's point. Nothing more. Of
>course, a full server will have sockets waiting for connections.
>
>
>

The services API has nothing to offer an embedded user since all the
services API actually does is invoke utilities on the server platform,
which for an embedded users, is this own machine. But again, as I told
Roman, the services API wil continue to be part of the product until
people forget it is there.

The administration server is a tool for remote administration. If there
ain't no remote administrating to be do, I don't figure an embedded user
will want to use it.

You may want to think about it a little more, but I consider the "buffer
overrun" issue for a component that hasn't been written to be at best
frivolous and at worst an example of a five year old's "don't wanna --
can't make me" tantrum. But to answer the question anyway:

1. The only fixed buffer will be the socket read buffer. I think we
can figure out that the max size of a read into "buffer" is
"sizeof(buffer)", but we may have to discuss it at length as well
as throw in a half dozen necessary casts of various types and flavors.
2. All other strings are allocated by JString after their length is
known by the XML parser.