Not a good idea; the design philosophy of Pike is that Pike-level code should never be able to cause memory corruption at C-level.
With ioctls there's no way to know what data a specific ioctl wants without reading the documentation for that specific ioctl for that specific OS. ioctls and fcntls are a way for device handlers to hook in APIs that aren't standard across all filedescriptors.
/ Henrik Grubbström (Lysator)
Previous text:
2004-08-17 13:32: Subject: managing comport settings in linux
What would be nice, is a way to define ioctl methods in Pike. Perhaps something like
object i = Stdio.IOCTL(4242 /* request_id */ ); i->add_int_parameter(); i->add_string_parameter(); i->set_return_type(STRING);
string ret = i(fd, 1, "somestring");
That ought to be possible, or..?
/ Marcus Agehall (PacketFront)
That's true. I think that is what you said when I brought the subject up.
I agree with the philosophy that Pike should never cause memory corruption at the C level to a certain extent. I think that there is room for advanced features that may break that principle if the user requests it.
If it would make you feel better, why not make it a standalone module for Pike. That way, noone should, by accident, fiddle with ioctls that may cause Pike to crash.
/ Marcus Agehall (PacketFront)
Previous text:
2004-08-17 13:41: Subject: managing comport settings in linux
Not a good idea; the design philosophy of Pike is that Pike-level code should never be able to cause memory corruption at C-level.
With ioctls there's no way to know what data a specific ioctl wants without reading the documentation for that specific ioctl for that specific OS. ioctls and fcntls are a way for device handlers to hook in APIs that aren't standard across all filedescriptors.
/ Henrik Grubbström (Lysator)
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Agehall (PacketFront) ＠ Pike (-) developers forum