Re: VC++ 2005 beta1 fails with pthreads benchmark tests

"David Schwartz" wrote
> "um" wrote
> > "David Schwartz" wrote
> >> "um" wrote
> >>
> >> > It is the last assert which fails in the first of the failing test
> >> > programs.
> >>
> >> Why should 'perror' be expected to cause an 'EGAIN' error? You need
> >> to
> >> test 'errno' before calling any library functions that might change its
> >> value. This code is broken.
> >
> > The code is not broken.
>
> It is.
>
> > In your quote you have left out the
> > relevant part of the code.
> > It is not perror which sets errno (funny imagination, btw).
>
> How do you know that?

Experience, and simple testing. Here is the proof. Take a look to the
lines with comments marked with "// UM"

void *
thr(void * arg)
{
sem_t s;
int result;
int errnoSav; // UM

assert(sem_init(&s, PTHREAD_PROCESS_PRIVATE, 0) == 0);

assert((result = sem_trywait(&s)) == -1);
errnoSav = errno; // UM
if ( result == -1 )
{
perror("thread: sem_trywait 1: expected error"); // No error
assert(errnoSav == EAGAIN); // UM: was "errno"; Error happens here (still)
}
else
{
printf("thread: ok 1\n");
}

....

> > errno is set by sem_trywait(). The code is:
>
> yes, it's set by 'sem_trywait', but then the code calls 'perror' before
> checking it!
>
> > assert((result = sem_trywait(&s)) == -1);
> > if ( result == -1 )
> > {
> > perror("thread: sem_trywait 1: expected error"); // No error
> > assert(errno == EAGAIN);
>
> Again, why would you expect 'perror' to set errno to 'EAGAIN'? Do you
> have some documentation that says 'perror' is guaranteed not to change
> errno?

No, it's not me, it's you who falsely thinks so. Therefore I've changed the code
to satisfy your view. But: the result is the same. The generated code of
VC++2005 crashes at the same location with the same error. Need more?
FYI: there are 122 test programs in total. 26 of them do fail with VC++2005
(see original posting for the list of the failing tests). Funny thing: VC++6
passes all tests flawlessly, so does the GNU compiler.

I hope it helps the developers at MS to fix the product. If more
info needed just let me know. BTW, I'm not involved in the
pthreads development; I'm just testing both products for suitability
and usability for some portable low-level hi-speed application projects
for Windows and Linux. Some of the developers insist on using
the latest product version, so I've first to check whether it makes sense,
or rather creates problems...




.

Relevant Pages

  • Re: When to use "perror" and "fprintf"
    ... >> range and set errno to ERANGE. ... the error message output by perror ... If they're identical, display only one, otherwise display ... Dan Pop ...
    (comp.lang.c)
  • Re: perror sets errno to "Illegal Seek"
    ... Calling perror() again may print out anything, ... you call a library function you can't depend on errno not being touched. ... *if* the function reports failure *and* the specification says the function ... not ESUCCESS otherwise". ...
    (comp.os.linux.development.apps)
  • Re: How to write to a file including full directory in C under Unix?
    ... copy the literal into a buffer and then use the buffer (for ... Use perror() or errno to show what was the error. ... have an appropriate newsgroups line in your header for your mail to be seen, ...
    (comp.lang.c.moderated)
  • Re: I dont understand the errors on this fork/exec
    ... First error code:: Success ... How come the first perror() prints 'Success'. ... perrorcan change the value of errno. ...
    (comp.unix.programmer)
  • Re: VC++ 2005 beta1 fails with pthreads benchmark tests
    ... >>> It is the last assert which fails in the first of the failing test ... >> Why should 'perror' be expected to cause an 'EGAIN' error? ... > It is not perror which sets errno ...
    (microsoft.public.dotnet.languages.vc)