fopen() on /dev/console

[Sebastian Huber]

On 14/02/2020 17:02, Joel Sherrill wrote:

> Hi
>
> I was porting some code from Linux to RTEMS. It doesn't use stdin/out,
> error directly but does all debug IO to a configured file. Most of the 
> time
> when running on Linux, the device is /dev/stderr. For the RTEMS port,
> I added link(/dev/console, /dev/stderr) to the init task and that worked.
The locking is done at the FILE object level, if you use multiple FILE 
objects with a single file descriptor you may get mixed output.
> But the application uses fopen(name, "w") to open the logging file.
> This works on Linux. On RTEMS, this failed because "w" implies
> ftruncate() and that returned -1.
>
> I got around this by changing the logging helper to use fopen(name, "a").
>
> I haven't done a POSIX deep dive and consulted with my POSIX contacts
> yet for a strict POSIX ruling but I think we probably want the "w" to work
> on RTEMS if it works on Lnux.
>
> I can put together a test case but I would like to settle on the accepted
> behavior first.

This is probably because of our rtems_filesystem_default_ftruncate() 
implementation:

int rtems_filesystem_default_ftruncate(
   rtems_libio_t *iop,
   off_t          length
)
{
   rtems_set_errno_and_return_minus_one( EINVAL );
}

Are there some rules for character devices? What happens on FreeBSD or 
macOS?