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 |
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 |
Free forum by Nabble | Edit this page |