XPG4

XPG4

[Alec Salazar]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

Is there any interest or plan to support the xopen xpg4 standard? My
specific interest is regarding zfs on linux. There is a function call
nl_langinfo(_DATE_FMT). Apparently this nl item was added in xpg4. I'm
wondering what the possibility is of a long-term solution.

Alec Salazar

[-- Attachment #2: Type: text/html, Size: 332 bytes --]

Re: XPG4

[Rich Felker]

On Thu, Aug 14, 2014 at 03:31:23PM -0400, Alec Salazar wrote:
> Is there any interest or plan to support the xopen xpg4 standard? My
> specific interest is regarding zfs on linux. There is a function call
> nl_langinfo(_DATE_FMT). Apparently this nl item was added in xpg4. I'm
> wondering what the possibility is of a long-term solution.

_DATE_FMT is just an incorrect or obsolete spelling for DATE_FMT. The
latter is standard and is supported by musl.

Rich

Re: XPG4

[Alec Salazar]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

I seem to be taking a wrong turn somewhere. Running find . -type f -print0
| xargs -0 /bin/grep D_FMT in /usr/include for the installed 1.1.4 yields:
./langinfo.h:#define D_FMT 0x20029
./langinfo.h:#define ERA_D_FMT 0x2002E
Pulling the latest sources and running the same command in gitdir yields:
./src/time/strptime.c:                  s = strptime(s, nl_langinfo(D_FMT),
tm);
./src/time/strftime.c:          item = D_FMT;
./include/langinfo.h:#define D_FMT 0x20029
./include/langinfo.h:#define ERA_D_FMT 0x2002E
Neither directory yields a result for DATE_FMT. Am I botching the unix-fu,
barking up the wrong tree or something else entirely?



On Thu, Aug 14, 2014 at 3:46 PM, Rich Felker <dalias@libc.org> wrote:

> On Thu, Aug 14, 2014 at 03:31:23PM -0400, Alec Salazar wrote:
> > Is there any interest or plan to support the xopen xpg4 standard? My
> > specific interest is regarding zfs on linux. There is a function call
> > nl_langinfo(_DATE_FMT). Apparently this nl item was added in xpg4. I'm
> > wondering what the possibility is of a long-term solution.
>
> _DATE_FMT is just an incorrect or obsolete spelling for DATE_FMT. The
> latter is standard and is supported by musl.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 1730 bytes --]

Re: XPG4

[Rich Felker]

On Thu, Aug 14, 2014 at 07:28:53PM -0400, Alec Salazar wrote:
> I seem to be taking a wrong turn somewhere. Running find . -type f -print0
> | xargs -0 /bin/grep D_FMT in /usr/include for the installed 1.1.4 yields:
> ../langinfo.h:#define D_FMT 0x20029
> ../langinfo.h:#define ERA_D_FMT 0x2002E
> Pulling the latest sources and running the same command in gitdir yields:
> ../src/time/strptime.c:                  s = strptime(s, nl_langinfo(D_FMT),
> tm);
> ../src/time/strftime.c:          item = D_FMT;
> ../include/langinfo.h:#define D_FMT 0x20029
> ../include/langinfo.h:#define ERA_D_FMT 0x2002E
> Neither directory yields a result for DATE_FMT. Am I botching the unix-fu,
> barking up the wrong tree or something else entirely?

Oh, perhaps it's my mistake and the proper name is D_FMT. Or did you
expect _DATE_FMT to give something different from what D_FMT gives?

Also I think you can just use %x directly to get this, rather than
looking it up via nl_langinfo first.

Rich

Re: XPG4

[Alec Salazar]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

Yes. D_T_FMT yields a similar output to _DATE_FMT, but it lacks the
timezone identifier. So I had thought to use the format specifiers directly
and bypass the call to nl_langinfo. I was told that _DATE_FMT was added
because Sun made everything up to date with the latest xopen std. I don't
yet grok the localization stuff. So, I'm wondering if passing the format
specifiers into strftime directly would remove any localizing done by
nl_langinfo?


On Thu, Aug 14, 2014 at 7:40 PM, Rich Felker <dalias@libc.org> wrote:

> On Thu, Aug 14, 2014 at 07:28:53PM -0400, Alec Salazar wrote:
> > I seem to be taking a wrong turn somewhere. Running find . -type f
> -print0
> > | xargs -0 /bin/grep D_FMT in /usr/include for the installed 1.1.4
> yields:
> > ../langinfo.h:#define D_FMT 0x20029
> > ../langinfo.h:#define ERA_D_FMT 0x2002E
> > Pulling the latest sources and running the same command in gitdir yields:
> > ../src/time/strptime.c:                  s = strptime(s,
> nl_langinfo(D_FMT),
> > tm);
> > ../src/time/strftime.c:          item = D_FMT;
> > ../include/langinfo.h:#define D_FMT 0x20029
> > ../include/langinfo.h:#define ERA_D_FMT 0x2002E
> > Neither directory yields a result for DATE_FMT. Am I botching the
> unix-fu,
> > barking up the wrong tree or something else entirely?
>
> Oh, perhaps it's my mistake and the proper name is D_FMT. Or did you
> expect _DATE_FMT to give something different from what D_FMT gives?
>
> Also I think you can just use %x directly to get this, rather than
> looking it up via nl_langinfo first.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2089 bytes --]

Re: XPG4

[Isaac Dunham]

On Thu, Aug 14, 2014 at 07:48:44PM -0400, Alec Salazar wrote:
> Yes. D_T_FMT yields a similar output to _DATE_FMT, but it lacks the
> timezone identifier. So I had thought to use the format specifiers directly
> and bypass the call to nl_langinfo. I was told that _DATE_FMT was added
> because Sun made everything up to date with the latest xopen std. I don't
Just a quick comment here:
xpg4 is not the latest X/Open standard, it's the oldest (early 1990s if I
remember correctly).
SUSv4(TC1)/POSIX2013 is the latest, and that's what musl is written to.

HTH,
Isaac Dunham

Re: XPG4

[Alec Salazar]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

Ok, gtk thanks.
Is there a functional difference between
-               fmt = nl_langinfo(_DATE_FMT);
+               fmt = "%c %Z";
as far as localization is concerned? fmt as the 3rd arg for strftime. I
imagine there is otherwise what's the use of nl_langinfo, but I haven't
been able to make sense of the locale docs yet. Or is it reasonable to
suggest adding string.h to concat the %Z on the end of nl_langinfo(D_T_FMT)?

On Thu, Aug 14, 2014 at 8:42 PM, Isaac Dunham <ibid.ag@gmail.com> wrote:

> xpg4 is not the latest X/Open standard, it's the oldest (early 1990s if I
> remember correctly).
> SUSv4(TC1)/POSIX2013 is the latest, and that's what musl is written to.
>
> HTH,
> Isaac Dunham
>

[-- Attachment #2: Type: text/html, Size: 1168 bytes --]