RPC_PROTOCOL_VERSION

classic Classic list List threaded Threaded
2 messages Options
raman raman
Reply | Threaded
Open this post in threaded view
|

RPC_PROTOCOL_VERSION


Hello,

I was going through the source code for LuaRPC. The function client_negotiate() defined in luarpc.c,
uses RPC_PROTOCOL_VERSION which is defined in an enumeration. char header[ 8 ] (defined in the same
function) holds this value to check for header validity before it can indicate e.errnum = ERR_HEADER; There
is also no possible way to typecast this directly. The RPC_PROTOCOL_VERSION can be changed to a character.

Please let me know if my observation is correct or if there's something I am overlooking.

Raman, Student.



_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: RPC_PROTOCOL_VERSION

On Sat, Jun 11, 2011 at 1:38 PM, Raman Gopalan <[hidden email]> wrote:

>
> Hello,
>
> I was going through the source code for LuaRPC. The function
> client_negotiate() defined in luarpc.c,
> uses RPC_PROTOCOL_VERSION which is defined in an enumeration. char header[ 8
> ] (defined in the same
> function) holds this value to check for header validity before it can
> indicate e.errnum = ERR_HEADER; There
> is also no possible way to typecast this directly. The RPC_PROTOCOL_VERSION
> can be changed to a character.
>
> Please let me know if my observation is correct or if there's something I am
> overlooking.

There's nothing special about char that prevents something that isn't
a character from being stored in it that's a value between 0 and 255.

From the C89 spec (not much different in C99):
"An object declared as type char is large enough to store any member
of the basic execution character set.  If a member of the required
source character set enumerated in $2.2.1 is stored in a char object,
its value is guaranteed to be positive.  If other quantities are
stored in a char object, the behavior is implementation-defined: the
values are treated as either signed or nonnegative integers."

Enumerated types are just integer constant values.

Generally, I suppose, many platforms treat it as an unsigned 8-bit
integer, so the enumerated value of 3 is perfectly small enough to fit
within the range that would be large enough to store a member of the
basic execution character set.

Now, I suppose that it might not be a bad idea to make the cast
explicit here to char for all of the parameters that are set in that
function, but I'm not sure if I would consider the existing version
broken or the source of the difficulties you're currently experiencing
(unless the compiler you're using is behaving differently than the
ones we've used previously :-) ).

The LuaRPC headers actually bear some resemblance to the Lua headers
used for compiled Lua files, and since that header generation code
does include explicit casts, I'll probably add this on my next pass
through the code since it's generally better to be explicit.

Lua's ldump.c DumpHeader, 259:
https://github.com/elua/elua/blob/master/src/lua/ldump.c

Best.

-jsnyder

>
> Raman, Student.
>
>
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev