RTEMS and unix directory

[Joel Sherrill]

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.

--joel

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


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