Euphoria
Ticket #238:
Fix global constants in socket.e to be platform independent.
-
Reported by
jimcbrown
Oct 22, 2010
Continutation of ticket:182
Moved the need to create new values for the constants into its own ticket. Not sure if this is blocking or can wait for post-4.0, it depends on whether or not changing the values of these constants is an API change or merely a textual bug fix.
Details
1. Comment by jimcbrown
Oct 22, 2010
Assigning to myself, if no one else wants to take a shot at it.
2. Comment by jimcbrown
Oct 27, 2010
See svn:3604 - this fixes most of the constants.
The socket options remain unchanged. The documentation explicitly states that the values are OS dependent and that the listing is incomplete (so the user may have to look up the values and enter raw hexadecimal numbers).
I'm not sure if we should change these over as well or leave them as they are.
3. Comment by ne1uno
Oct 28, 2010
http://euphoria.pastey.net/142184
reformatted the socket options to highlight options in common, using r3627 version of socket.e
eudoc apparently will not show duplicate options, but then it appears that any option might work on any OS. this is a rough draft, it may still have a creole error. will work on it more later.
4. Comment by jimcbrown
Oct 28, 2010
I think I've come up with a compromise.
The options already defined in std/socket.e will be defined on all platforms, in a cross-platform manner. A new machine_func() will be provided to convert these Euphoria-specific enums to the platform-specific option.
In the C backend, we'd do stuff like
case ESO_DEBUG:
#ifdef SO_DEBUG
return SO_DEBUG;
#else
return 0;
#endif
Now, however, the question is now to modify get_option() and set_option() to use these values.
We could require the user to call the new machine_func() every time and do the conversion manually, but that's clumsy. The other choice is to have get_option() and set_option(), and get_raw_option() and set_raw_option() - so if the user needs to use an option that's not known to the backend, they call the raw version of the routine.
Ideally, get_option() and set_option() would know if a given option was raw or the Euphorian enum and do the right thing, but I'm not sure if this is possible.
5. Comment by mattlewis
Oct 28, 2010
Maybe we do the conversion all in the back end? So eu code only ever knows the generic versions.
6. Comment by jimcbrown
Oct 28, 2010
The documentation states
If you should
need to set socket options, please refer to your OS reference material.
There may be other values that your OS defines
It'd be a pain to have to release a new version of Euphoria because we have to update the backend everytime an OS is upgraded to support some new obscure SO option.
7. Comment by jeremy
Oct 28, 2010
The error codes are done that way Matt, but how do you expose all the options via the backend? There are many, many options. Doing things like:
public enum
SO_BLOCKING = 1,
SO_NONBLOCKING,
SO_XYZABC
makes it pretty easy:
sock:set_options(my_sock, { sock:SO_BLOCKING, sock:SO_XYZABC })
8. Comment by mattlewis
Oct 28, 2010
Well, we either tell people to refer to their OS documentation or the socket functionality of euphoria (the std lib and the runtime) is cross platform from a euphoria code standpoint.
I suppose one way around that would be to use sequences for the cross platform versions, so we have to convert those. We could keep them as bitmaps (i.e., {1}, {2}, {4}, ...) so the normal operations would apply. Then we convert those (wherever we decide) to the appropriate OS dependent values. Otherwise, if the user supplies atoms, we just pass those through without conversion.
9. Comment by jeremy
Oct 28, 2010
The method right now is to use constants inside of ifdefs. So the user always does:
sock:set_option(my_sock, sock:SO_HELLO_WORLD)
regardless of what platform they are on.
Now, that only works for options that are cross-platform. Linux has some options that Windows does not, BSD has others and OS X has yet others.
So, I think it's a mixture of Euphoria is cross-platform sockets and see your OS docs. Common things should be cross platform but if you get into the nitty-gritty of things for your platform, you'll have to resort to your own platform checks.
10. Comment by jimcbrown
Oct 28, 2010
The documentation states
If you should
need to set socket options, please refer to your OS reference material.
There may be other values that your OS defines
It'd be a pain to have to release a new version of Euphoria because we have to update the backend everytime an OS is upgraded to support some new obscure SO option.
11. Comment by jimcbrown
Oct 28, 2010
The only way to have cross-platform enums for common options and OS specific values for others, would be to do what Matt describes. Matt's idea effectively solves the problem.
12. Comment by jimcbrown
Oct 29, 2010
I redid this in svn:3676 to use JeremyC's idea of using C to figure out which constants are defined. We also have Euphoria-specific constants that are designed to keep the same value across platforms and OSes, but they require the user to do manual conversion.
Users can also specify raw integers to the relevant functions, in case they want to take advantage of a new socket option or suck tha the Euphoria backend doesn't support yet.
13. Comment by ne1uno
Oct 30, 2010
see Ticket:265
I had to change some of the origional markup to work around a one off error in the enum list.
do they even have to be public? there could be a getter if someone actually needed an integer of which socket option.
it's a regular bug festival. shouldn't this have worked?
Ticket:265
I entered instead
[[http://openeuphoria.org/ticket/265.wc#265|Ticket:265]]
14. Comment by jimcbrown
Oct 30, 2010
I will redo them to be a series of constants "ESO_... = 1, ESO_... = 2, ..."
I am not sure if they should be made public or not. My original idea was that create() and get_sockopt(), etc would use the raw OS value but if a person's code needed to have a value that was cross-platform (say, they're doing something weird like persisting socket option flags in a db and then reloading them on a different OS) then they could just add an E in front of those constants.
However, that concept may have only very limited utility. Obviously, we should default to having them private (so they're not part of the API, and not something that has to be supported forever) and then possibly revisit the issue post-4.0
15. Comment by jimcbrown
Oct 31, 2010
The constants have been redone. Some documentation may be left, but this ticket is finished.
GitHub