This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Rhamphoryncus
Recipients Rhamphoryncus, georg.brandl, gustavo, gvanrossum, jdemeyer
Date 2019-04-09.21:03:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1554843836.74.0.675381269398.issue1583@roundup.psfhosted.org>
In-reply-to
Content
Converting to/from sig_atomic_t could have a compile time check on currently supported platforms and isn't buggy for them.  For platforms with a different size you could do a runtime check, only allowing a fd in the range of 0-254 (with 255 reserved); that could sometimes fail, yes, but at least it's explicit, easily understood failure.  Just using int would fail in undefined ways down the road, likely writing to a random fd instead (corrupting whatever it was doing), with no way to trace it back.

Unpacking the int would mean having one sig_atomic_t for 'invalid', using that instead of INVALID_FD, plus an array of sig_atomic_t for the fd itself.  Every time you want to change the fd you first set the 'invalid' flag, then the individual bytes, then clear 'invalid'.
History
Date User Action Args
2019-04-09 21:03:56Rhamphoryncussetrecipients: + Rhamphoryncus, gvanrossum, georg.brandl, gustavo, jdemeyer
2019-04-09 21:03:56Rhamphoryncussetmessageid: <1554843836.74.0.675381269398.issue1583@roundup.psfhosted.org>
2019-04-09 21:03:56Rhamphoryncuslinkissue1583 messages
2019-04-09 21:03:56Rhamphoryncuscreate