Re: fdprintf() Anyone?

On 2025-12-12 07:39, Joel Sherrill wrote:
> On Fri, Dec 12, 2025, 4:06 AM Brian Inglis wrote:
> 
>     For a quick check on most newlib functions, search Cygwin compatibility pages:
> 
>     https://cygwin.org/cygwin-api/compatibility.html <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 <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.

Cygwin documents system interfaces compatible with:

	the Single UNIX® Specification Version 5
	BSD functions
	GNU or Linux extensions
	Solaris or SunOS functions
	ISO C requirements but not in POSIX

	Other UNIX® system interfaces, not in POSIX.1-2024, or deprecated:
	Other system interfaces, some from Windows
	NOT implemented system interfaces from SUS Version 5

It is generated in standard GNU manual formats from DocBook XML:

https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml

along with the rest of the newlib libc/libm and Cygwin docs in those formats.

FYI am glad to report that ISO/IEC/IEEE 9945:2025 Ed.2 is in FDIS final ballot 
stage, closing on 2026-01-24:

	https://mail-archive.com/[email protected]/msg14070.html

	https://www.iso.org/standard/91911.html

which will add ISO/IEC approval to the latest standard version.

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

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

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