This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libgloss/libnosys: Add fcntl and ioctl.


With the separation of newlib and libgloss, one libgloss
implementation may not provide a certain symbol, while another may.
It's even reasonable for the user to provide a libgloss implementation
that newlib has no control over. For this reason, it's not reasonable
for newlib to compile out usage of fcntl because one libgloss
implementation doesn't provide it.

By way of example, I found that freopen(NULL, ...) fails on arm-elf
because freopen refuses to call fcntl if HAVE_FCNTL is not defined. A
more general solution is to simply call fcntl and check for ENOSYS, in
which case libnosys should provide fcntl.

To summarize my argument, at the time of compiling newlib, newlib
shouldn't presume anything about what features libgloss will provide
at the link time of a user application.

Cheers,
Shaun

On 5/18/06, Jeff Johnston <jjohnstn@redhat.com> wrote:
What is the reasoning for adding this?

The calls to _fcntl and _fcntl_r in the newlib library are protected
with HAVE_FCNTL.  For user code, libc/syscalls adds an fcntl stub
routine in the case where HAVE_FCNTL is not set.

Nothing in shared newlib calls _ioctl.  The sys directories that
reference _ioctl supply the syscall.  That said, you reference a
sys/ioctl.h header file which doesn't exist in newlib/include/sys so
this won't build on most platforms.

-- Jeff J.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]