public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@Shaw.ca>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH] fix(libc): Fix handle of %E & %O modifiers at end of format string
Date: Mon, 13 Nov 2023 11:46:46 -0700	[thread overview]
Message-ID: <0649bde5-ba16-40bf-a5b1-00ae7b676292@Shaw.ca> (raw)
In-Reply-To: <ZVJSDAyKK/h8bZa/@calimero.vinschen.de>

On 2023-11-13 09:42, Corinna Vinschen wrote:
> Hi Pedro,
> 
> On Nov 11 18:29, Pedro Luis Castedo Cepeda wrote:
>> OK. It's not a newlib problem but a GLib one as it is relaying on common but
>> non-standard strftime implementation details.
>>
>> I attach a short program more focused in g_date_strftime implementation so
>> it can be evaluated if it worths addressing this corner case.
> 
> Tricky.  I wonder what the GLib test is actually trying to accomplish.
> 
> POSIX has this to say:
> 
>    RETURN VALUE
>      If the total number of resulting bytes including the  terminating
>      null byte  is not more than maxsize, these functions shall return
>      the number of bytes placed into the array pointed to by s, not
>      including the  terminating NUL character. Otherwise, 0 shall be
>      returned and the contents of the array are unspecified.
> 
>    ERRORS
>      No errors are defined.
> 
> But, and that's the big problem, POSIX does *not* provide for the
> error case, because it doesn't allow an error like using an incorrect
> format string to occur.  Using an incorrect or undefined format code
> is just not part of the standard.
> 
> And the Linux man page has an interesting extension to the above
> POSIX RETURN VALUE section:
> 
>      Note  that  the  return value 0 does not necessarily indicate an
>      error.  For example, in many locales %p yields an empty string.  An
>      empty  format string will likewise yield an empty string.
> 
> and additionally in the BUGS section:
> 
>      If the output string would exceed max bytes, errno is  not  set.
>      This makes it impossible to distinguish this error case from cases
>      where the format  string  legitimately  produces  a  zero-length
>      output  string.  POSIX.1-2001 does not specify any errno settings
>      for strftime().
> 
> So the below case tested by GLib is entirely out of scope of the
> standard.

C 2023 draft says:

"7.29.3.5 The strftime function
...
     Returns
8   If the total number of resulting characters including the terminating null
character is not more than maxsize, the strftime function returns the number of 
characters placed into the array pointed to by s not including the terminating 
null character. Otherwise, zero is returned and the members of the array have an 
indeterminate representation."

GLib is not tested under Cygwin/newlib only VS2017 and Msys2-Mingw32 native 
Windows:

https://gitlab.gnome.org/GNOME/glib/-/issues/2604

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2480/diffs

https://gitlab.gnome.org/malureau/glib/-/pipelines/366193/test_report

[may need to navigate not always obvious "tabs"]

Should raise a followup issue there - and point out it is not a Win32 issue - it 
is another POSIX alternate libc issue - hosted under a Win64 environment.

-- 
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 à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

      reply	other threads:[~2023-11-13 18:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09 19:04 Pedro Luis Castedo Cepeda
2023-11-10  6:17 ` Brian Inglis
2023-11-10 10:16   ` Corinna Vinschen
2023-11-10 17:44     ` Pedro Luis Castedo Cepeda
2023-11-11  5:57       ` Brian Inglis
2023-11-11 17:29         ` Pedro Luis Castedo Cepeda
2023-11-13 16:42           ` Corinna Vinschen
2023-11-13 18:46             ` Brian Inglis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0649bde5-ba16-40bf-a5b1-00ae7b676292@Shaw.ca \
    --to=brian.inglis@shaw.ca \
    --cc=cygwin-patches@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).