Bug in strptime() function

[WW304289]

I've run into what appears to be a bug in strptime() function on VMS. Attached reproducer.

Thanks,
-Boris

t.c
---
#include
#include

int main() {
struct tm tms;
if ( !strptime("20080125", "%Y%m%d", &tms) )
puts("OOPS!");
}

$ cc/ver
HP C V7.3-018 on OpenVMS IA64 V8.3
$ pipe cc t.c ; link t.obj ; run t.exe
OOPS!
$

$ uname -a
Linux ... x86_64 GNU/Linux
$ cc t.c && ./a.out
$

[Clarete Riana]

Hi,

The input string and the format string both need spaces after year, month and date values. Find below the modified program that works.

#include
#include

int main() {
struct tm tms;
if ( !strptime("2008 01 25", "%Y %m %d", &tms) )
puts("OOPS!");
}

[Joseph Huber_1]

Riana,
sorry, but this just confirms the CRTL implementation on VMS is flawed:
nothing in the description requires white-space between the conversion items.

On linux (and other systems ?) it simply works.
If the Xopen/Posix standards tell it different, please cite; otherwise CRTL should be corrected, such a form of date is really not unusual, e.g. in tables sorted by date/time.

[Hoff]

The language lawyers may (will?) have a split decision here, but it's looking like this behavior diverges from that of gcc. (There are other areas of that divergence, though.)

Here's gcc 4.0.1.


$ cc x.c
f$ ./a.out
20080125
200801
200825
$ cat x.c
#include
#include
#include

int main() {
struct tm tms;
if ( !strptime("20080125", "%Y%m%d", &tms) )
puts("20080125");
if ( !strptime("200801", "%Y%m", &tms) )
puts("200801");
if ( !strptime("200825", "%Y%d", &tms) )
puts("200825");
if ( !strptime("2008", "%Y", &tms) )
puts("2008");
if ( !strptime("20080", "%Y", &tms) )
puts("20080");
if ( !strptime("0125", "%m%d", &tms) )
puts("0125");
exit( EXIT_SUCCESS );
}


Here is gcc 4.2.1...

$ cc x.c
$ ./a.out
$

[Craig A Berry]

Riana is half right. The standard at:

http://www.opengroup.org/onlinepubs/7990989775/xsh/strptime.html

clearly states, regarding the format string, "There must be white-space or other non-alphanumeric characters between any two conversion specifications." Other C libraries clearly do not comply with this requirement.

However, there is no reason that the string being scanned should also need whitespace between fields. The CRTL does not comply with that aspect of the standard.

There is unfortunately no good alternative to writing code that works everywhere regardless of what the standard says, testing that it does so, and being prepared to rewrite the code when the standard and/or the implementations catch up with each other.

[Joseph Huber_1]

Thanks for clarification Craig.
The CRTL HELP then correctly represents the standard.

IMHO the standard should more clearly tell that conversion items must be separated by either a white-space or other characters, one of the two must be present; so it is clear that %Y%m%d is not a legal format.
The present wording rather suggests delimiters between conversion items are optional.

[Hoff]

Another case of being technically correct and operationally wrong? Ah, well.

That's never a fun tradeoff; you're wrong either way you go.

The ftp server has fallen into a similar hole. TCP/IP Services is technically correct, and operationally incompatible.

I'd hope for a gcc or clang compilation mode for newer OpenVMS compilers (to better work with gnv and such), but then I've encountered piles of (inherently buggy) VAX C code recently; old stuff.

[Dennis Handly]

>Craig: there is no reason that the string being scanned should also need whitespace between fields.

Huh? If it exists in the format, it must be there in the string.

I suppose one way to allow no delimiters is to fully specify (or assume) the widths.

[Joseph Huber_1]

>>I suppose one way to allow no delimiters is to fully specify (or assume) the widths.

One might think so, but apparently neither VMS nor GNU has implemented it this way.

[Joseph Huber_1]

i.e.

strptime("20080125", "%4Y%2m%2d", &tms)

gives error in both VMS and GNU systems.

[Joseph Huber_1]

I finally think the sentence
"There must be white-space or other non-alphanumeric characters between any two conversion specifications." in the XOPEN specification
leaves no room for formats without delimiters,
so one can't write portable programs using "yyyymmdd with "%Y%m%d", although GNU apparently uses inherent
field width of 4-2-2 to parse it.

[WW304289]

I also think that the requirement "There must be white-space or other non-alphanumeric characters between any two conversion specifications" makes format specification "%Y%m%d" illegal. Thanks for pointing it out. So, this is not a bug in the CRTL, as I thought, but rather an undefined behaviour.

Having said that, the CRTL has no problem processing this call:

strptime("2008x01x25", "%Yx%mx%d", ...)

which as also illegal. It is obvious why the function fails for "%Y%m%d" and succeeds for "%Yx%mx%d". I just wish the undefined behaviour in both cases would be the same, and I don't mean failure in both cases :-)

Thanks for all the replies,
-Boris

[Hoff]

gcc 4.2.1 does not return an error with the example I posted.

An older gcc did return the errors (shown).

But again, a case can be made for standards compliance, and an equally good case can be made for gcc compliance.

[Joseph Huber_1]

WW304289,
If You desparately need -because there are datasets containing these formats- , then the WGET source I found on this link
http://sourceforge.jp/cvs/view/simplechart/wget/cmpt.cpp?view=co

contains a strptime working, which can replace the VMS CRTL by
cc/prefix=(all,except=strptime) .

(needs a few #defines, or remove all other routines).

[WW304289]

"If You desparately need -because there are datasets containing these formats- , then the WGET source ..."

Thanks for the suggestion. I've already implemented workaround (in fact, before I even posted this to an HP Forum) so, I'm all set. Just wanted to bring this problem to the attention of CRTL developers.

Thanks again,
-Boris

[Steven Schweda]

> [...] the WGET source I found on this link
> [...]

Wow. You don't already _have_ wget source?

http://antinode.info/dec/sw/wget.html

Who could live without wget?

That link seems to have some wget 1.10.2
code, modified (into C++) for some particular
non-VMS system.

(My wget-for-VMS builders seem to claim
HAVE_STRPTIME, so they're using the C RTL
strptime().)

[John Gillings]

Boris,

>Just wanted to bring this problem to the
>attention of CRTL developers.

Unfortunately you're unlikely to achieve that by posting anything here.

Although this is an official HP web site, there is very little participation by HP engineers. If you want to make sure HP engineering knows about an issue, you'll need to raise a formal case with your local customer support centre.

[Manjula M]

Hello,

In OpenVMS CRTL subroutine strptime(), when more than one format specifier is present, they must be separated by white space or a non-% [percent sign]/non-alphanumeric ordinary character.

The call to strptime API with the following format does pass on OpenVMS as expected: strptime("2008x01x25", "%Yx%mx%d", ...)

Please find below a snapshot of description in the CRTL Reference Manual on OpenVMS

" Any character other than the percent character (%) or a white-space character. This directive causes the function to read the next character.
The character read must be the same as the character that comprises the directive. If the character is different, the function fails. "

Best Regards,
Manjula
[OpenVMS CRTL Engineering]

[Hoff]

That the OpenVMS manuals and the C standards here say that this C code can be safely claimed as broken (or non-portable, non-compliant, or whatever euphemism) is quite clear.

That's not the nub of the question that I see here.

The nub of the question is which standard(s) will be the ones OpenVMS will comply with?

Whether that's going to continue to be the Unix and C standards (as is presently the case), or whether those extensions and features and changes and, yes, oddities of gcc are (also) a valid compliance target?

I'm locally dealing with far more gcc code going forward, and have thought about porting gcc or clang and the libraries over to OpenVMS. (In addition to differences in strptime, the getopt_long call is entirely missing, for instance.)

There is definitely no right answer here. That's the fun of standards-compliance. There are just so many of them around to choose from.

[Dennis Handly]

>the CRTL has no problem processing this call:
strptime("2008x01x25", "%Yx%mx%d", ...)

HP-UX detects this as illegal.

>ME: I suppose one way to allow no delimiters is to fully specify (or assume) the widths.

This doesn't work any better on HP-UX. strptime(3) says what Craig quoted.

Not even %4.4Y%2.2m%2.2d works.