This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Recent 4.1 breakage...


In article <446CFED6.1050704@suse.de>, Paolo Carlini<pcarlini@suse.de> writes:

> Humpf, I'm sorry, in the meanwhile I was testing the below, and I would 
> be rather happy with it ;) I'm simply putting to good use our VERIFY 
> machinery (*finally*, some people would add, I'm sure). The patch is 
> very safe, basically the tests themselves are unchanged, and could still 
> be run with _GLIBCXX_ASSERT defined, in case of need. Is it fine with you?

Yea, of course.  There is still an open issue (in my mind) that VERIFY
status of a child process is not signaled to the test harness.

>> Well, I'm confused on the expected behavior of 26777 (even after
>> reading the PR) and exactly what I see on FreeBSD 5.  Here is the read
>> on the fifo and the lseek from a truss log:

>> 82979: read(0x3,0x804d000,0x3ff)                 = 8 (0x8)
>> 82979: lseek(3,0xfffffffffffffff8,SEEK_CUR)      = 0 (0x0)

>> Paolo, make any sense to you?

> Not really, *on the spot*, sorry (it's late here in Italy...). But I 
> want to understand what's going on. Can you print to cout the failing 
> oss.str()? Is it empty or not? Out of curiosity, which is the value of 
> BUFSIZ on FreeBSD?

It was empty.

#define    BUFSIZ  1024

Regards,
Loren


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]