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

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?
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?


Attachment: ttyname.c
Description: ttyname.c

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