public inbox for ecos-bugs@sourceware.org help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001914] New: cyg_io_select behaves as "device ready" when the device driver actually doesn't support select? Date: Sun, 10 Nov 2013 23:46:00 -0000 [thread overview] Message-ID: <bug-1001914-777@http.bugs.ecos.sourceware.org/> (raw) Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001914 Bug ID: 1001914 Summary: cyg_io_select behaves as "device ready" when the device driver actually doesn't support select? Product: eCos Version: 3.0 Target: All Architecture/Host Other OS: Status: UNCONFIRMED Severity: normal Priority: low Component: Other Assignee: unassigned@bugs.ecos.sourceware.org Reporter: vlad_a_pudovkin@hotmail.com CC: ecos-bugs@ecos.sourceware.org The cyg_io_select seems to be not covered by the official eCos reference guide; the only sort of "spec" I found for it was this snippet from the header packages/io/common/<version>/include/io.h: // Test a device for readiness cyg_bool cyg_io_select(cyg_io_handle_t handle, cyg_uint32 which, CYG_ADDRWORD info); The code of this function (file packages/io/common/<version>/src/iosys.c) seems to try to encode one "special value" into type cyg_bool: cyg_bool cyg_io_select(cyg_io_handle_t handle, cyg_uint32 which, CYG_ADDRWORD info) { cyg_devtab_entry_t *t = (cyg_devtab_entry_t *)handle; // Validate request if (!t->handlers->select) { return -EDEVNOSUPP; } return t->handlers->select( handle, which, info ); } There are two issues with this "special value": 1) This return statement issues a compiler warning like this: implicit conversion from 'int' to 'cyg_bool' (aka 'unsigned char') changes value from -202 to 54 2) It is somewhat confusing to have one peculiar "true" value to actually indicate an error while other "true" values mean that the device is ready. The whole ecos code does not seem to contain examples of using the return value of this function, which otherwise could help figuring out the "recommended" way of using that return value. This lack of cyg_io_select usage examples in the whole ecos code makes me wonder whether this is a widely used function or rather a work in progress? -- You are receiving this mail because: You are the assignee for the bug.
next reply other threads:[~2013-11-10 23:46 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-11-10 23:46 bugzilla-daemon [this message] -- strict thread matches above, loose matches on Subject: below -- 2013-11-10 23:46 bugzilla-daemon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-1001914-777@http.bugs.ecos.sourceware.org/ \ --to=bugzilla-daemon@bugs.ecos.sourceware.org \ --cc=unassigned@bugs.ecos.sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).