RTEMS and unix directory

[Jeff Johnston]

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.
> http://www.opengroup.org/onlinepubs/009695399/functions/ttyname.html
> says:
> "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
> decided
> 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
> better
> 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,

  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: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
> On Behalf Of Joel Sherrill
> Sent: Wednesday, November 12, 2008 10:55 AM
> To: newlib@sources.redhat.com
> Subject: RTEMS and unix directory
>
> Hi,
>
> 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?
>
> ...
>