RE: svn commit: r565221 - /incubator/stdcxx/trunk/tests/src/char.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 9:01 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r565221 - /incubator/stdcxx/trunk/tests/src/char.cpp [EMAIL PROTECTED] wrote: Author: faridz Date: Sun Aug 12 18:47:17 2007 New Revision: 565221 URL: http://svn.apache.org/viewvc?view=revrev=565221 Log: 2007-08-13 Farid Zaripov [EMAIL PROTECTED] * char.cpp (rw_widen): Don't write after end of dst. Why not? I.e., what was wrong with the code before the change? If there is a bug, does the 0.char.cpp test catch it? (If not, it should be enhanced.) Partially :) The 0.char.cpp test issues Access Violation in 12d build on MSVC. Farid.
Re: expectation vs requirements for locale facets
Travis Vitek wrote: Martin Sebor wrote: Yes. But notice the text doesn't say anything about time_put_byname or time_get_byname ;-) Well, the standard doesn't say much at all about the *_byname facets. All it really says about them is [21.1.1.2 p4] For some standard facets a standard ..._byname class, [...] The _byname requirements are extremely vague. Sometimes they are also implied by the requirements on the base facets, which makes them difficult to find. It's a mess. So, if I'm reading that right, the *_byname facet classes are just there to prevent the user from having to instantiate a std::locale directly. I'm not sure what you mean by this. The _byname facets are really just an implementation that's exposed in the interface if the locale library. They should have never been specified. The C++ standard (or even the C standard for that matter) isn't going to of help here. Wait. Say what now? I'm not sure what you're trying to tell me here. If the C++ Standard says that these facets read or write years as roman numerals, then they should probably do so, regardless of what any other standard document requires. I think this will actually get cleared up in a few seconds... The C and C++ standards only specify the requirements on the C locale and leave the localized behavior unspecified. So pretty much anything goes. There are some ground rules but I suspect you won't be able to tease the requirement on swallowing leading space for the %e directive out of them. Of course that isn't what I'm seeing. Test case? Yeah. See attachment. Only tested on Win32/VC8 and Linux/GCC. Thanks. Here are the results with stdcxx and with g++ 3.4.6: $ ./t.stdcxx | grep fail string=07/06/08 result=fail locale=thai string= 7.06.1908 result=fail locale=bg_BG string=07/06/08 result=fail locale=lo_LA string=07/06/08 result=fail locale=th_TH $ ./t.gcc | grep fail string=��� %.1d ��� 1908result=fail locale=ar_SA string=۰۸/۰۶/۰۷ result=fail locale=fa_IR string=ಗುರುವಾರ 07 ಜೂ 1908 result=fail locale=kn_IN Looks like g++ is failing on multibyte character sequences but not on the spaces. We seem to somehow manage to process the multibyte sequences (I wonder how, or if it's a weakness in the test) but have issues with the leading space in bg_BG. I don't know what the problem is with the other locales... It's hard to say from just looking at the code (and I haven't looked very carefully). In general, we [try to] to implement the POSIX semantics, so if it works with strptime()/strftime() it should work with our time_put_byname/ time_get_byname. Well, there's the problem right there. The standard requires that the time_put facet format its output according to the POSIX function strftime(), with the option for supporting extensions. It makes no indication that the time_get facet should read data in such a way as to be compatible with strptime(). The only thing I see that says anything about the format expecte by time_get is here... [...] Right. Pretty vague. This paragraph says that time_get::get_date() is supposed to process the output of time_put::put(..., 'x'). [22.2.5.1.2 p4] Effects: Reads characters starting at s until it has extracted those struct tm members, and remaining format characters, used by time_put::put to produce the format specified by 'x' or until it encounters an error. Yes. The problem with the C++ standard in this area is that the requirements a vague and not always implementable (e.g., the multibyte sequences -- all the narrow specializations of the _get facets operate on single characters). If we test this behavior it's gotta be right ;-) Where does POSIX say leading spaces must be skipped? I see this under %e: Equivalent to %d. And under %d: The day of the month [01,31]; leading zeros are permitted but not required. Nothing about ignoring spaces. Absolutely. The docs for POSIX strftime()... [...] So strftime() isn't even compatible with strptime() when it comes to '%e'. Hmm. That seems like a bug in POSIX then, unless we're missing something. You might want to create a POSIX-only test case to verify this and if I'm right open a discussion on the Austin Group list (http://www.opengroup.org/austin/lists.html). [...] Unfortunately, without consistent input/output it is going to be difficult for this multi-threading test to verify that no data corruption is occuring with arbitrary locales. Hopefully there is some system in place that allows us to explicitly specify which locales are to be used for a test. Not really. My approach would be to detect locales with this problem and avoid using them. The test also doesn't need to be exhaustive, at least not in this iteration. I think exercising just the most common patterns should be good enough (although %X is pretty common :) Martin
Re: how does rw_locales() work on Windows?
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Saturday, August 18, 2007 1:41 AM To: stdcxx-dev@incubator.apache.org Subject: how does rw_locales() work on Windows? The rw_locales() function defined in the driver invokes the locale -a command regardless of the platform (i.e., including Windows). When I run tests that invoke the function from within the IDE they produce errors because the locale utility can't be found (it's probably not in PATH). I'm curious: how do others run tests on Windows so that calls to rw_locales() succeed ? Farid? When I debug the single test, I have just copy locale.exe and localedef.exe (and libstdxx.dll in dynamic builds) to some directory in the path (i.e. c:\windows) and remove them later. I see. That doesn't seem very convenient. I suppose the problem is essentially the same as with stdcxx.dll not being in PATH when I try to run programs from the IDE. It seems that we should have a solution for this quirk. I can't see people being happy with having to manually copy executables in order to run them. Do you have any suggestions for how to deal with it? Martin
RE: how does rw_locales() work on Windows?
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 21, 2007 6:38 PM To: stdcxx-dev@incubator.apache.org Subject: Re: how does rw_locales() work on Windows? Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Saturday, August 18, 2007 1:41 AM To: stdcxx-dev@incubator.apache.org Subject: how does rw_locales() work on Windows? When I debug the single test, I have just copy locale.exe and localedef.exe (and libstdxx.dll in dynamic builds) to some directory in the path (i.e. c:\windows) and remove them later. I see. That doesn't seem very convenient. I suppose the problem is essentially the same as with stdcxx.dll not being in PATH when I try to run programs from the IDE. It seems that we should have a solution for this quirk. I can't see people being happy with having to manually copy executables in order to run them. Do you have any suggestions for how to deal with it? We can't set PATH just before run test from the IDE - there is no Pre-Run step. The MSVC8 IDE has Envoronment field in Debugging page of the Project Properties dialog, but this field can be changed only manually. So we should either add %BUILDDIR%/bin in the PATH before run IDE or copy locale.exe and localedef.exe to the tests directory at Post-Build step. Both solutions are not convinient as for me. Farid.
Re: svn commit: r563682 - in /incubator/stdcxx/trunk/src: once.cpp once.h
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 7:39 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r563682 - in /incubator/stdcxx/trunk/src: once.cpp once.h Thanks for pointing it out! I noticed it too when I tested the change on Windows but I haven't decided how to deal with it yet. Compilers often assume that functions with C linkage don't throw exceptions and generate code that breaks when an exception does end up being thrown. I think MSVC is one of them, and gcc another. We should probably add a config test to determine whether a compiler allows exceptions to pass through C code and only rethrow the exception only when it does. In the opposite case we'll need to decide how to handle the exception. Any suggestions? Why the internal function should be extern C? So they can be passed to pthread_create() which is in all cases I know of a C interface (i.e., it expects a pointer to a function with a C language linkage as an argument). Functions with different language linkage have distinct types and are incompatible with one another. Most compilers including MSVC and gcc) don't implement this rule and as a result present a serious portability problem. See the following gcc bug report for an example of such a problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Martin
RE: svn commit: r563682 - in /incubator/stdcxx/trunk/src: once.cpp once.h
I'm sure you mean pthread_once() not pthread_create(). :) Martin Sebor wrote: Farid Zaripov wrote: Any suggestions? Why the internal function should be extern C? So they can be passed to pthread_create() which is in all cases I know of a C interface (i.e., it expects a pointer to a function with a C language linkage as an argument). Functions with different language linkage have distinct types and are incompatible with one another. Most compilers including MSVC and gcc) don't implement this rule and as a result present a serious portability problem. See the following gcc bug report for an example of such a problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Martin
Re: svn commit: r563682 - in /incubator/stdcxx/trunk/src: once.cpp once.h
Travis Vitek wrote: I'm sure you mean pthread_once() not pthread_create(). :) Yes, that's what I meant, thanks. (Even though the issue with pthread_create() would be the same.) Martin Martin Sebor wrote: Farid Zaripov wrote: Any suggestions? Why the internal function should be extern C? So they can be passed to pthread_create() which is in all cases I know of a C interface (i.e., it expects a pointer to a function with a C language linkage as an argument). Functions with different language linkage have distinct types and are incompatible with one another. Most compilers including MSVC and gcc) don't implement this rule and as a result present a serious portability problem. See the following gcc bug report for an example of such a problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Martin
Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
Farid Zaripov wrote: From: Martin Sebor [mailto:[EMAIL PROTECTED] I just found out that the /Ehc flag enables the nothrow default for C linkage functions. So changing the /EHsc flag to /EHs will fix this for both VC7 and 8. Do you happen to know if there's a #pragma that will let us select the mode we need for just the one function? There's no #pragma for that, but we can compile all cpp files with /Ehsc, and some set of specified files with /EHs. But, there is __declspec(throw) - right?
Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Saturday, August 18, 2007 12:00 AM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp I just found out that the /Ehc flag enables the nothrow default for C linkage functions. So changing the /EHsc flag to /EHs will fix this for both VC7 and 8. Do you happen to know if there's a #pragma that will let us select the mode we need for just the one function? There's no #pragma for that, but we can compile all cpp files with /Ehsc, and some set of specified files with /EHs. Okay, that's something to consider. We'll have to see how pervasive the use of __rw_once() will be as soon as I'm done switching to it (so far I think it'll be needed in only a handful of places) and whether any of the initialization functions will potentially throw. Btw., from the MSVC Exception Handling Model: http://msdn2.microsoft.com/en-us/library/1deeycx5(VS.80).aspx it looks like by default the compiler generates code that makes catch blocks catch structured exceptions (in addition the C++ kind). That's generally considered bad practice, but it may be relied on by user code for historical reasons. We need to be careful not to impose requirements on our users that would go against this historical practice (doing so could break working code). Martin
Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
William A. Rowe, Jr. wrote: Farid Zaripov wrote: From: Martin Sebor [mailto:[EMAIL PROTECTED] I just found out that the /Ehc flag enables the nothrow default for C linkage functions. So changing the /EHsc flag to /EHs will fix this for both VC7 and 8. Do you happen to know if there's a #pragma that will let us select the mode we need for just the one function? There's no #pragma for that, but we can compile all cpp files with /Ehsc, and some set of specified files with /EHs. But, there is __declspec(throw) - right? There is __declspec(nothrow) to indicate that a function cannot throw exceptions (the default for C functions) but I don't see one to indicate the opposite, i.e., that a C function can throw. One would think it'd be the logical extension given that all C++ functions can throw by default and no C functions can. Here's the latest man page on __declspec(nothrow): http://msdn2.microsoft.com/en-us/library/49147z04(VS.80).aspx Martin
RE: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 21, 2007 9:36 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp William A. Rowe, Jr. wrote: Farid Zaripov wrote: From: Martin Sebor [mailto:[EMAIL PROTECTED] I just found out that the /Ehc flag enables the nothrow default for C linkage functions. So changing the /EHsc flag to /EHs will fix this for both VC7 and 8. Do you happen to know if there's a #pragma that will let us select the mode we need for just the one function? There's no #pragma for that, but we can compile all cpp files with /Ehsc, and some set of specified files with /EHs. But, there is __declspec(throw) - right? There is __declspec(nothrow) to indicate that a function cannot throw exceptions (the default for C functions) but I don't see one to indicate the opposite, i.e., that a C function can throw. One would think it'd be the logical extension given that all C++ functions can throw by default and no C functions can. You're right. But there is throw(...) exception specification which tells the compiler that the function can throw an exception. http://msdn2.microsoft.com/en-us/library/wfa0edys(VS.80).aspx Farid.
Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 21, 2007 9:26 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp There's no #pragma for that, but we can compile all cpp files with /Ehsc, and some set of specified files with /EHs. Okay, that's something to consider. We'll have to see how pervasive the use of __rw_once() will be as soon as I'm done switching to it (so far I think it'll be needed in only a handful of places) and whether any of the initialization functions will potentially throw. I've just tried to declare and define __rw_once with throw(...) exception specification and compiler doesn't issues warning in that case. Good to know! We still need to decide how to handle this in the general case (for compilers that behave like MSVC, if there are any) but we can certainly start using this extension to silence the MSVC warnings. Btw., from the MSVC Exception Handling Model: http://msdn2.microsoft.com/en-us/library/1deeycx5(VS.80).aspx it looks like by default the compiler generates code that makes catch blocks catch structured exceptions (in addition the C++ kind). That's generally considered bad practice, but it may be relied on by user code for historical reasons. We need to be careful not to impose requirements on our users that would go against this historical practice (doing so could break working code). It was by default only in MSVC versions prior 7.0 (because the only asynhronous exceptions handling model was implemented. Since MSVC 7.0 they added synhronous exceptions handling model and this model is used by default. Thanks for the clarification! I've also discovered it in the docs since I sent my mail. Martin
RE: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
Martin Sebor wrote: Farid Zaripov wrote: I've just tried to declare and define __rw_once with throw(...) exception specification and compiler doesn't issues warning in that case. Yes, but the documentation linked to explicitly says... Explicit exception specifications are not allowed on C functions. [http://msdn2.microsoft.com/en-us/library/wfa0edys(VS.80).aspx] I tested, it does compile, and the destructors are getting called as they should when an explicit throw(...) spec is added to the C linkage function. That said, I cringe at the thought relying on behavior that is documented to not work or is not supported. Maybe when the documentation is referring to C functions it means functions that are compiled as C source [x.c instead of x.cpp] and not functions with C linkage? Good to know! We still need to decide how to handle this in the general case (for compilers that behave like MSVC, if there are any) but we can certainly start using this extension to silence the MSVC warnings. Is the goal really to just squelch the warnings? I hope not. So back at square one, I have another question. Lets assume a program will abort() if an exception is thrown through a C function. This characterization test will fail, and the build framework will probably set a preprocessor flag _RWSTD_NO_EXTERN_C_EXCEPTIONS. What exactly would we do to prevent this from being a problem? I can think of two things. 1. Add a try/catch block inside every once function definition that might throw. 2. Implement our own pthread_once() type function that has C++ linkage and use it with all configurations on all platforms. Both solutions are compatible with all systems, and would eliminate the warning on MSVC as a side effect. Obviously the first option isn't that pleasant because there is no _good_ way I can see to communicate a failure back to the application. Is there something wrong with the second option? Travis
RE: expectation vs requirements for locale facets
Martin Sebor wrote:
The C and C++ standards only specify the requirements on the C
locale and leave the localized behavior unspecified. So pretty
much anything goes.
I don't know how you can say that with a straight face. The C++ standard
says that time_put::put() treats the format string like strftime().
The C and POSIX specifications both define the output for strftime() for
each of the required format specifiers. The numeric values are pretty
strictly specified, and the non-numeric ones [%b as an example] are
supposed to be defined by the specified locales LC_TIME category.
It seems pretty well defined, it is just through three levels of
indirection. It makes sense to not define the behavior for all locales
explicitly in the C standard, since locale definition files can be
created by the user, and the system provided ones could be modified or
removed.
There are some ground rules but I suspect
you won't be able to tease the requirement on swallowing leading
space for the %e directive out of them.
I wouldn't think so, but I might not need to. See below...
Well, there's the problem right there. The standard requires that the
time_put facet format its output according to the POSIX function
strftime(), with the option for supporting extensions. It makes no
indication that the time_get facet should read data in
such a way as
to be compatible with strptime(). The only thing I see that says
anything about the format expecte by time_get is here...
[...]
Right. Pretty vague.
I guess you could interpret that as vague. I mean they don't explicitly
say you can't try to emulate strptime(). Of course they don't explicitly
say you should attempt to either.
They do, on the other hand, say that the put() should behave
consistently with strftime(), and that get_*() should be able to read
the output of put() for a given format.
Absolutely. The docs for POSIX strftime()...
[...]
So strftime() isn't even compatible with strptime() when it
comes to '%e'.
Hmm. That seems like a bug in POSIX then, unless we're missing
something. You might want to create a POSIX-only test case to
verify this and if I'm right open a discussion on the Austin
Group list (http://www.opengroup.org/austin/lists.html).
Yeah, I've made a testcase using strptime(), but it passes on most
environments I've tested. Source...
#include stdio.h
#include time.h
#include assert.h
#include string.h
int main (int argc, char* argv [])
{
const char* fmt = -%H:%M:%S-%m/%e/%Y-;
const char* buf = -01:02:03-04/ 5/1906 -;
struct tm r;
memset (r, 0, sizeof (r));
strptime (buf, fmt, r);
fprintf (stderr, %%H=%d %%M=%d %%S=%d %%m=%d %%e=%d %%Y=%d\n,
r.tm_hour, r.tm_min, r.tm_sec,
r.tm_mon, r.tm_mday, r.tm_year);
assert (1 == r.tm_hour); // [01,12]
assert (2 == r.tm_min); // [00,59]
assert (3 == r.tm_sec); // [00,61]
assert (3 == r.tm_mon); // [00,11]
assert (5 == r.tm_mday); // [01,31]
assert (6 == r.tm_year); // [00,99]
return 0;
}
The strptime() function is clearly skipping leading whitespace with the
'%e' flag on those platforms that allow this test to pass. Here is a
quick test matrix
Pass | Fail |
+---+---+
Linux26/gcc346 | X | |
Solaris58/SunPro53 | X | |
HP-UX11/ACC373 | | X |
DEC5.1/C++71 | X | |
+---+---+
Win32/VC8 | no strptime() |
My approach would be to detect locales with this
problem and avoid using them. The test also doesn't need to
be exhaustive, at least not in this iteration. I think
exercising just the most common patterns should be good enough
(although %X is pretty common :)
Yes, I could verify the locale doesn't use '%e' to represent weekdays
for the time being.
Martin
Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
Travis Vitek wrote: Martin Sebor wrote: Farid Zaripov wrote: I've just tried to declare and define __rw_once with throw(...) exception specification and compiler doesn't issues warning in that case. Yes, but the documentation linked to explicitly says... Explicit exception specifications are not allowed on C functions. [http://msdn2.microsoft.com/en-us/library/wfa0edys(VS.80).aspx] Yet they describe the behavior of functions, including those with C linkage, in terms of explicit exception specification. How ironic! I tested, it does compile, and the destructors are getting called as they should when an explicit throw(...) spec is added to the C linkage function. That said, I cringe at the thought relying on behavior that is documented to not work or is not supported. No kidding! Maybe when the documentation is referring to C functions it means functions that are compiled as C source [x.c instead of x.cpp] and not functions with C linkage? Who knows... Have you tried it? Good to know! We still need to decide how to handle this in the general case (for compilers that behave like MSVC, if there are any) but we can certainly start using this extension to silence the MSVC warnings. Is the goal really to just squelch the warnings? I hope not. No, not just that (we could simply use #pragma warning to silence them if that was the only goal). So back at square one, I have another question. Lets assume a program will abort() if an exception is thrown through a C function. This characterization test will fail, and the build framework will probably set a preprocessor flag _RWSTD_NO_EXTERN_C_EXCEPTIONS. What exactly would we do to prevent this from being a problem? I can think of two things. 1. Add a try/catch block inside every once function definition that might throw. 2. Implement our own pthread_once() type function that has C++ linkage and use it with all configurations on all platforms. Both solutions are compatible with all systems, and would eliminate the warning on MSVC as a side effect. Obviously the first option isn't that pleasant because there is no _good_ way I can see to communicate a failure back to the application. Is there something wrong with the second option? Good questions. I suppose the potential overhead would be my biggest concern. The solution we discussed recently on another list (overloading pthread_once() for extern C++ functions) involves dynamically allocating a small chunk of memory. That's a steep price to pay for one time initialization. But we might be solving a non-issue. I'm not sure yet that there are any one-time initializers in the library that can throw an exception. So I think we're safe until we've actually found one that does. Although it surely would be nice to have a robust solution in place just in case we add an initializer that can throw in the future. Btw., there is another alternative: For compilers like MSVC that ignore the difference between extern C and extern C++ functions (i.e., where _RWSTD_NO_EXTERN_C_COMPATIBILITY is #undefined) we can just pass extern C++ functions to __rw_once(). Martin
RE: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
Martin Sebor wrote: Maybe when the documentation is referring to C functions it means functions that are compiled as C source [x.c instead of x.cpp] and not functions with C linkage? Who knows... Have you tried it? I have now. The compiler chokes on 'throw' when compiling C sources as it should. Good questions. I suppose the potential overhead would be my biggest concern. The solution we discussed recently on another list (overloading pthread_once() for extern C++ functions) involves dynamically allocating a small chunk of memory. That's a steep price to pay for one time initialization. Well we wouldn't need to do that as the entire system would be implemented in C++. You already provide such an implementation for the windows configuration. But we might be solving a non-issue. I'm not sure yet that there are any one-time initializers in the library that can throw an exception. So I think we're safe until we've actually found one that does. Although it surely would be nice to have a robust solution in place just in case we add an initializer that can throw in the future. Agreed, and agreed.
RE: expectation vs requirements for locale facets
Travis Vitek wrote: The strptime() function is clearly skipping leading whitespace with the '%e' flag on those platforms that allow this test to pass. Here is a quick test matrix Doh! I messed up the header row on that table, which might have caused some confusion. Here is the corrected table. Pass | Fail | +---+---+ Linux26/gcc346 | X | | Solaris58/SunPro53 | X | | HP-UX11/ACC373 | | X | DEC5.1/C++71 | X | | +---+---+ Win32/VC8 | no strptime() |
Re: expectation vs requirements for locale facets
Travis Vitek wrote: Martin Sebor wrote: The C and C++ standards only specify the requirements on the C locale and leave the localized behavior unspecified. So pretty much anything goes. I don't know how you can say that with a straight face. How do you know what face I made when I said it? ;-) The C++ standard says that time_put::put() treats the format string like strftime(). The C and POSIX specifications both define the output for strftime() for each of the required format specifiers. The numeric values are pretty strictly specified, and the non-numeric ones [%b as an example] are supposed to be defined by the specified locales LC_TIME category. You're right about %e -- the C standard leaves no wiggle room there. It must expand to the day of the month with single-digit numbers having to be preceded by a space. But %b (or %x and %X) can expand to anything at it need not even be parseable. [...] I guess you could interpret that as vague. I mean they don't explicitly say you can't try to emulate strptime(). Of course they don't explicitly say you should attempt to either. They do, on the other hand, say that the put() should behave consistently with strftime(), and that get_*() should be able to read the output of put() for a given format. Yes, but don't the get_time() and get_date() functions also say that they only parse the output produced by %H:%M:%S and %m/%d/%y (or some such combination of the individual directives)? Btw., the next standard contains some useful enhancements to the time_get facet: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2321.html [...] Yeah, I've made a testcase using strptime(), but it passes on most environments I've tested. Source... [test program snipped] The strptime() function is clearly skipping leading whitespace with the '%e' flag on those platforms that allow this test to pass. Here is a quick test matrix Interesting. So strptime(%e) swallows the leading space on all of these platforms (plus AIX) except HP-UX. I'd be inclined to say that they're all buggy, but that wouldn't help us much. I think I'll need to ask on the POSIX list what the intended behavior actually is. They usually tend to standardize existing practice so even if the intent is not to consume whitespace since pretty much all platforms do, I suspect they'll either go with it or make it unspecified. Martin PS I enhanced your test case to exercise the behavior in all locales installed on each system and it still passed on the two platforms I tried (AIX and Linux) and failed on HP-UX.
Re: [PATCH] STDCXX-522
Everton Araujo wrote:
Sorry Martin, I didn't observe the coding style ... my bad. I'll change it
right now.
About the test, I think it's good for avoiding unnecessary xsputn calls
considering that it just exists when char count (__nchar) is equals 0.
Perhaps it is. But if it's not necessary to fix the bug such
a change should be made in a separate patch to minimize the
scope of the bugfix. We try to highlight this guideline on
our bugs page but possibly not be as clearly as we should:
http://incubator.apache.org/stdcxx/bugs.html#patch_format
May I suggest something? (If not, jmp _end)
Yes! Please do! :) Suggestions for improvements are welcome!
I think you would consider
transform xsputn in an inline function which may call _xsputn (the full
implementation) just when count greater than 0, automatically avoiding
unnecessary calls. What do you think about it? Please remember, it's just a
suggestion, don't hate me, give me a smile :-)
I assume you're proposing to add a new inline function that
would be used internally by our implementation (we can't change
the name xsputn() since it's a required interface). That might
be something to consider, although there already is a public
inline function called sputn() that presumably could be used
for this *if* the standard requirements on it were relaxed so
as to allow it to return without calling xsputn() when its
second argument is 0. The other issue with calling sputn()
from overflow() is that it would end up calling the xsputn()
defined in a derived class, which is not permitted by the
standard (that's why the call to xsputn() is qualified with
the name of basic_filebuf). So this will need some thought.
Thanks again for your suggestion and the patch. I'll test it
and commit it as soon as I've seen successful test results.
Martin
_end:
The test is not required for correct patch behavior. You may ignore it with
no regards. :-)
Regards.
Everton.
2007/8/18, Martin Sebor [EMAIL PROTECTED]:
Everton Araujo wrote:
Thank you Martin and Andrew for helping me.
Below is the patch for STDCXX-522 (std::filebuf::overflow(EOF) writes
EOF to
file in unbuffered mode)
Thanks for the patch! I have a couple of questions for you but first
let me make a general comment about our formatting style. The stdcxx
style guidelines haven't been migrated from Rogue Wave to Apache yet,
so until we have migrated them, contributors like you need to try to
figure them out by observing the existing code they are patching.
A couple of the basic ones are:
1. Use 4-space indents (no TABs).
2. Separate every opening parenthesis, bracket, or curly brace
from the preceding symbol by a single space.
So by the way of example, ...
Index: include/fstream.cc
===
--- include/fstream.cc(revision 566470)
+++ include/fstream.cc(working copy)
@@ -351,8 +351,15 @@
_RWSTD_STREAMSIZE __nchars;
if (__unbuf) {
+ if(this-_C_is_eof(__c)){
...this should be (note the two additional spaces before the if
and the one space after the if, after _C_is_eof, and before the
open curly brace):
+if (this-_C_is_eof (__c)) {
Now for the questions...
+_C_cur_pos.state (0);
+__buf = 0;
+__nchars = 0;
+ }
+ else{
__buf= __c_to_char;
__nchars = 1;
+ }
}
else {
// call xsputn() with a special value to have it flush
@@ -364,7 +371,7 @@
// typedef helps HP aCC 3.27
typedef basic_filebuf _FileBuf;
-if (__nchars != _FileBuf::xsputn (__buf, __nchars))
+if (__nchars __nchars != _FileBuf::xsputn (__buf, __nchars))
Why is the extra test here necessary? I.f., why wouldn't the original
code be sufficient?
return traits_type::eof (); // error while writing
}
@@ -424,7 +431,7 @@
typedef basic_filebuf _FileBuf;
// return -1 on error to flush the controlled sequence
-if (__nwrite != _FileBuf::xsputn (__special, __nwrite))
+if (__nwrite __nwrite != _FileBuf::xsputn (__special,
__nwrite))
Why is this change necessary at all?
Martin
Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
Travis Vitek wrote: Martin Sebor wrote: Maybe when the documentation is referring to C functions it means functions that are compiled as C source [x.c instead of x.cpp] and not functions with C linkage? Who knows... Have you tried it? I have now. The compiler chokes on 'throw' when compiling C sources as it should. Makes sense. So I wonder what the heck the purpose of throw(...) is supposed to be given that every C++ function is always (regardless of any compiler switches) implicitly declared with it and if it's not allowed on C functions (clearly it *is* allowed if the compiler accepts it, so what gives?) Martin
RE: expectation vs requirements for locale facets
-Original Message- From: [EMAIL PROTECTED] Sent: Mon, 20 Aug 2007 05:20:32 -0600 To: stdcxx-dev@incubator.apache.org Subject: RE: expectation vs requirements for locale facets Mark Brown wrote: In my experience, the time_get facet isn't always able to reliably parse international times and cannot parse every time string produced by the time_put facet. Yes, I see two different problems here. You can generate output with time_put::put for which there is no matching time_get method for parsing that data. What I mean is that you can easily format %S %p onto the stream, but there is no method in the time_get facet for reading that formatted data back. The stdcxx implemention provides an extension that allows you to do this, but it's an extension. The other problem is the one that I'm more concerned about. I don't remember ever having problems with spaces though. Yeah, that is the problem. It is my interpretation that this is a requirement, but I'm not sure that anyone agrees with me on this. I don't really see the point in defining a system for input/output of times and dates if you can't read in the values that you write out. Yeah, that wouldn't be a terribly useful system... On Linux at least, stdcxx has no problems skipping leading space in time strings. That is inconsistent with what I'm seeing. [see partial failure lists below] You're right! I was sure I had used stdcxx to parse time strings with spaces in them but now that I've tried it I must acknowledge it really doesn't work. My sincere apologies for confusing the discussion! -- Mark
