This is the mail archive of the 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: RTEMS and unix directory

Thanks Craig. It is nice to be able to eliminate duplication. :-D

Jeff.. at this point, you have merged all my patches.   I will start
looking at the unix directory now.


Jeff Johnston wrote:
Howland Craig D (Craig) wrote:
I see a couple of problems with the proposed ttyname.c.
First, it appears to have a mistake in how ttyname_r() works.
"Upon successful completion, ttyname() shall return a pointer to a
string. Otherwise, a null pointer shall be returned and errno set to
indicate the error.
If successful, the ttyname_r() function shall return zero. Otherwise, an
error number shall be returned to indicate the error."
The given ttyname_r() sets errno with the error, but has a constant
return of -1 for errors. While the C99 standard allows functions to
set errno even when the use of errno has not been defined for that
function, I would think that it would be better if it didn't.
Secondly, the namesize parameter is ignored, so that name could be
overrun if the user did not allow enough space. (Unfortunately, the
fix for this entails a fairly large array on the stack.)
Attached is an alternate proposal, which I made following your lead,
but started with the file from the unix directory. (I was wondering
what was going on with the spurious rval in the rtems file, and so
to start with the earlier file.) The unix directory file that I started
with was in unix format in contrast to your DOS file, so use -b if doing
a diff.
An interesting question is the exact error return values. I used what
rtems did except in two cases. First, the tcgetaddr() error return is
used instead of fixed EBADF, as tcgetaddr() can return EBADF or ENOTTY.
Second, if the given fd turns out to not be a character device, I
thought that ENOTTY is better than EBADF. (It's not perfect, but it
fits better than saying the fd is bad.)
Additionally, there's a question as to what ought to be returned if
opendir() fails. I left it as EBADF, as given the choices in POSIX for
ttyname EBADF is as good as ENOTTY, but neither one of them are really
accurate. It is permitted to have other error returns than what POSIX
specifically calls for, but I couldn't decide what might be enough
to change to. ENODEV and ENOENT were the best candidates that I found
for the opendir() call. Thoughts on going to one of them?

Thanks for the replacement. I have checked it in to the libc/unix directory and added a check for #ifndef _NO_TTYNAME which allows platforms to skip the code if desired by defining _NO_TTYNAME. I will be adding similar flags to the other routines in lib/unix.

FWIW: I thought your assessment of what to return on failure was fine as-is.

-- Jeff J.
Craig Howland

-----Original Message-----
From: []
On Behalf Of Joel Sherrill
Sent: Wednesday, November 12, 2008 10:55 AM
Subject: RTEMS and unix directory


After examining how RTEMS could use the posix
subdirectory, I moved onto the unix subdirectory.

Our ttyname.c appears to have originated with
the one in this directory but has been slightly
modified to have ttyname_r.  So our version
could go in here and be used.  I have attached
it for review.

Is the configure/build infrastructure able to
turn on just the pieces listed above and ttyname.c
if you are OK with our version?


Joel Sherrill, Ph.D.             Director of Research & Development        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985

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