Re: fdprintf() Anyone?

On Fri, Dec 12, 2025, 4:06 AM Brian Inglis <[email protected]>
wrote:

> For a quick check on most newlib functions, search Cygwin compatibility
> pages:
>
>         https://cygwin.org/cygwin-api/compatibility.html
>
> bearing in mind that Cygwin may have its own variants supporting hosted
> features
> like multiple character sets, IPC, languages, locales, time zones, and
> similar.
>

Ironically we have something similar for RTEMS which tracks APIs versus
various standards and versions. It includes multiple versions of POSIX
including the PSE profiles, C standard, FACE Technical Standard, Software
Communications Architecture (SCA).

https://docs.rtems.org/docs/main/posix-compliance.html

If anyone cares, most of that document is generated from a CSV of a
spreadsheet and a Python script.

If anyone knows of a standard that profiles POSIX for embedded systems
that's not covered there, please let me know.

The problem is just that I didn't remember dprintf() or never knew about
it. It has been in newlib for twenty years. If an RTEMS user wanted it, it
was just there with no need to ask questions. This time someone is using a
non-standard name for it and asked.

--joel



> On 2025-12-11 17:38, Joel Sherrill wrote:
> > Thank you for the quick response and pointing out the POSIX standard
> functions!!!
> >
> > I am honestly quite happy not to have to seriously add anything
> non-standard.
> >
> > Looking at the git log, these have been in newlib a LONG time.
> >
> > Thanks again.
> >
> > --joel
> >
> > On Thu, Dec 11, 2025 at 6:19 PM John Scott wrote:
> >
> >     Joel Sherrill wrote:
> >      > int fdprintf (int fd, const char *format,...)
> >
> >     POSIX.1-2008 has already standardized a version of printf() for
> writing to
> >     file descriptors, and it has the same prototype: it's called dprintf
> >     (without the 'f' at the beginning). There is also a va_list variant
> named
> >     vdprintf(). These are widely available and I think GNU folks drove
> their
> >     specification.
> >
> >     These are already included at https://sourceware.org/git/?p=newlib-
> >     cygwin.git;a=blob;f=newlib/libc/stdio/dprintf.c <
> https://sourceware.org/
> >     git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/dprintf.c>
> however I
> >     think the following text is no longer accurate:
> >      > PORTABILITY
> >      > This function is originally a GNU extension in glibc and is not
> portable.
> >
> >     Post-standardization I think implementations picked this up without
> >     hesitation. You probably just missed this; in fact, dprintf()
> returns the
> >     same value as fdprintf() does to indicate success or error. I think
> the
> >     NetBurner folks giving their function a different name was, at least
> in
> >     hindsight, a botch.
> >
> >      > But the user is using a system where they are in <fcntl.h>.
> >     For compatibility with that particular application I'm sure you
> could make
> >     fdprintf() an alias for dprintf(). If a user is wanting to use
> Newlib with
> >     NetBurner such a shim might be welcome in a directory specific to
> that class
> >     of systems.
> >
> >      > Is there any interest in these eventually landing in newlib?
> >     The equivalent standard functions are already in Newlib and my
> preference
> >     (as someone who, to be frank, has never contributed to Newlib) is to
> do
> >     nothing here. If your users are porting an application away,
> defining '-
> >     Dfdprintf=dprintf' may be all they need to do.
>
> --
> Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada
>
> La perfection est atteinte                   Perfection is achieved
> non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to
> add
> mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to
> cut
>                                  -- Antoine de Saint-Exupéry
>