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)