[Bug libstdc++/29354] New: Error when seeking on an ostringstream
The function seekp(pos_type) fails on an empty stream,
even when the target position is the value returned
by tellp.
---
#include
#include
#include
int
main()
{
std::ios::pos_type const
err = std::ios::pos_type( std::ios::off_type( -1 ) ) ;
std::ostringstream os ;
std::ios::pos_type pos = os.tellp() ;
if ( pos == err ) {
std::cout << "tell failed" << std::endl ;
} else {
os.seekp( pos ) ;
if ( ! os ) {
std::cout << "seek failed" << std::endl ;
}
}
return 0 ;
}
---
Outputs "seek failed". According to the standard,
seekp() calls seekpos() in stringbug, which can
only fail (here) if the position is invalide.
And tellp() cannot return an invalide position
other than -1 (correctly casted).
--
Summary: Error when seeking on an ostringstream
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkanze at cheuvreux dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29354
[Bug bootstrap/27133] New: Fails to build because of funny version of makeinfo
This may actually be several distinct minor bugs.
On my Sparc machine, I have what I think is a strang
version of makeinfo, installed by TeX (or at least,
in the tex tree) -- makeinfo --version returns:
makeinfo (GNU texinfo 3.12) 1.68
This results in the compiler system (most specifically
fastjar) failing to build.
I will apply the obvious fix in my case -- install
a correct version of makeinfo from sources. However...
The makeinfo pages say that "all GNU distributions should come
with prebuilt info files, thus makeinfo should not be needed.
If you notice a distribution that does not come with *.info files,
please report it as a bug." Whence this bug report.
Two possible improvements while I'm at it: there really
could be an error message (or a warning) in configure, where
you check the version, and (more a question) is there a simple
way to build without building the documentation -- I've already
got it from the Linux build anyway?
--
Summary: Fails to build because of funny version of makeinfo
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkanze at cheuvreux dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug bootstrap/27133] Fails to build because of funny version of makeinfo
--- Comment #3 from jkanze at cheuvreux dot com 2006-04-13 16:28 --- (In reply to comment #1) > Are you building from a release version, correct? As far as I know. It's version 4.1.0, downloaded yesterday or the day before. How can I tell? (I do want something more or less stable, since I'm using the compiler in production code.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug c++/27216] New: Wrong lifetime of temporary, calls destructor twice
In the following code, the lifetime of the temporary
bound to the static const reference in g() is wrong.
In fact, the destructor is called every time the function
is left (although the constructor is called only the
first time the function is entered, which is correct).
According to the C++ standard, the lifetime of a temporary
bound to a reference should be identical to that of the
reference -- in this case, the destructor should not
be called until final clean-up.
The compiler was invoked without any options. Running
the generated a.out reveals multiple calls to the destructor.
- code -
#include
#include
class C
{
public:
C( char id ) ;
C( C const& other ) ;
~C() ;
private:
charmyId ;
} ;
void
g()
{
static C const& c = C( 'g' ) ;
std::cerr << "in g" << std::endl ;
}
int
main()
{
g() ;
g() ;
return 0 ;
}
C::C( char id )
: myId( id )
{
std::cout << "ctor: " << myId << " (@" << this << ")" << std::endl ;
}
C::C( C const& other )
: myId( other.myId )
{
std::cout << "copy: " << myId << " (@" << this << ")" << std::endl ;
}
C::~C()
{
std::cout << "dtor: " << myId << " (@" << this << ")" << std::endl ;
}
--
Summary: Wrong lifetime of temporary, calls destructor twice
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkanze at cheuvreux dot com
GCC build triplet: sparc-sun-solaris2.8, i686-pc-linux-gnu
GCC host triplet: sparc-sun-solaris2.8, i686-pc-linux-gnu
GCC target triplet: sparc-sun-solaris2.8, i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27216
[Bug driver/27276] New: Option -static-libgcc doesn't work
When linking C++ programs (i.e. invoking g++), libstdc++ and libgcc_s are linked dynamically, even when -static-libgcc is given as an option. This causes the linked programs to crash or hang on systems using different versions of g++, or simply if my path happens to be set to a different version of g++. (I suspect the reason here is that I am using -D_GLIBCXX_DEBUG, etc., and that the older versions of the library didn't support this.) What I think I need here is to link libstdc++, so I can be independant of the LD_LIBRARY_PATH and the version of the installed g++ libraries on the target machine, but to link libc dynamically, so that the executable will run on different versions of Solaris. My impression from the documentation was that -static-libgcc should do this. -- Summary: Option -static-libgcc doesn't work Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkanze at cheuvreux dot com GCC build triplet: sparc-sun-solaris2..8 GCC host triplet: sparc-sun-solaris2..8 GCC target triplet: sparc-sun-solaris2..8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27276
[Bug libstdc++/21334] New: Lack of Posix compliant thread safety in std::basic_string
ll holds iterators refering to it,
and despite the fact that there is still a global variable
(usable after the pthread_joins in main) which depends on
it.
The problem is, of course, that the sequence which tests whether
we have to leak, and then leaks, is not atomic.
--
Summary: Lack of Posix compliant thread safety in
std::basic_string
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkanze at cheuvreux dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-02 13:22 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string Looks like it. The example function at the user level isn't the same, but the basic problem is. I'd forgotten I ever sent the first one. At some point, I read somewhere that G++ didn't want to support multiple accesses from different threads, even if there was no modification. I'd mentionned this in various news groups, and Gabriel Dos Reis took me to the task: he said that if there was no modification in either thread, I should submit it as a bug. I guess my real question is the same one with which the previous bug ended: is this an error, or is this the intended behavior. If it is an error in the code, then it needs correcting not only in the code, but in the text which I cited from the library FAQ. (If it is the intended behavior, of course, you're going to hear a lot of complaints from those of us used to the Posix model:-).) -- James "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-02 13:30 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> Two quick comments: 1- I'd like to keep open either 10350 or |> this one, I don't see much value in keeping open both. Ok? In that case, I'd go for this one. It mentions one of the places where g++ documentation suggests that this shouldn't work. And it mentions the Posix standard as an argument as to why it should. |> 2- I'm not aware of any real cure for this kind of problems |> within a RC implementation. Are you? pthread_mutex_lock:-). Of course, performance will take a serious hit. -- James Kanze mailto:[EMAIL PROTECTED] Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:34 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> Isn't this a bug as opposed to "enhancement"? Enhancement |> suggests that the behaviour is basically correct, but could be |> improved. I could accept that. The behavior *is* conforme with your documentation, even if it isn't conforme with what Posix normally requires. -- James Kanze "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:37 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> Does the C++ standard mention multithreading and Posix |> threads? ;) No, but the g++ installation procedures do. According to the installation procedured, with the options I gave on generation, the compiler supports the Posix thread model. Or are you suggesting that g++ should return to the pre-3.0 position that multithreaded programs don't exist, or aren't interesting to g++ users. -- James Kanze "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:56 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> >I am sending this to the g++ bug list on the recommendation of |> >Gabriel Dos Reis. From what little I've read in the g++ |> >documentation, I'm not convinced that the authors of the g++ |> >library intend for it to be supported, although Posix would seem |> >to require it. |> Firstly, POSIX says nothing about C++ thus my confusion starts here. The statement I quoted from the Posix standard is language neutral. A priori, it applies to all languages. |> Secondly, it is clear that your bug report is hypothetical. The |> library maintainers do not typically deal in hypotheticals. I guess it is really a question of whether you want quality or not. In general, all code is supposed incorrect until proven otherwise -- in the case of threading issues, this is particularly important, because of the random factors involved. In this particular case, there is only a very, very small window of time in which the error can occur. I could add a lot of extra code, which would only obfuscate the real problem, but would increase the chances that the error occurs. I could probably, experimentally, add just the right amount so that the error occurred more or less regularly (say one execution in ten) on my machine. Unless your machine had exactly the same configuration (processor, clock speed, background processes, etc.), the error would probably not trigger there. |> >For the record, the statement in Posix is: "Applications shall |> >ensure that access to any memory location by more than one |> >thread of control (threads or processes) is restricted such that |> >no thread of control can read or modify a memory location while |> >another thread of control may be modifying it." The obvious |> >extension to C++ is that of replacing "memory location" with |> >"object"; at the very least, of course, one can only require |> >something of "memory locations" which the user sees, directly or |> >indirectly. |> OK. |> >The statement in the libstdc++-v3 FAQ (question |> >5.6) is: "All library objects are safe to use in a multithreaded |> >program as long as each thread carefully locks out access by any |> >other thread while it uses any object visible to another thread, |> >i.e., treat library objects like any other shared resource. In |> >general, this requirement includes both read and write access to |> >objects; unless otherwise documented as safe, do not assume that |> >two threads may access a shared standard library object at the |> >same time." |> OK, I seem to recall editing that statement at one point... |> >A considerably weaker guarantee than what one |> >normally expects under Posix. (Note that the clause "like any |> >other shared resource" is simply false for those of us used to |> >the Posix model. If I replace std::string with char[] in my |> >code below, the behavior is perfectly defined under Posix.) |> No, confusion. We are guaranteeing that if you lock the visible |> accesses to global or otherwise shared objects, that no POSIX |> threading rule will be violated within our own library code. Well, there's certainly some confusion, because Posix says one thing, and your documentation says another. When you say "treat library objects like any other shared resources', you are contradicting yourself for a system using the Posix model. In the case of string, of course, the obvious "other' system resource to compare it with is char[]. If you replace std::string with char[], in my example program, the code is well defined and guaranteed to work under Posix. |> We are |> saying that we guarantee that any internal shared objects (which may |> not be visible to the user, thus not lockable by the user) will be |> correctly handled per POSIX threading rules. I know what you are guaranteeing (in the statement above). It's because of this statement (or a similar one elsewhere in the documentation) that I hadn't sent in a bug report, but that I did take the bother of warning people in various news groups that in g++, std::string did not behave as one would normally expect. You can use it, but you have to take additional precautions that Posix says shouldn't be necessary, and that experienced Posix users don't expect to need. An implementation, of course, is free to decide what it wants to guarantee, and what it doesn't. If it is decided, however, that the Posix guarantees do not extend to the library, then it is important to document this fact; i.e. to indicate somewhere that it cannot be missed that configuring
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 09:09 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> Whereas I'm all for providing alternate memory management |> policies (we are very close to that in the v7-branch and I |> promise further progress during the next months) I fail to |> properly appreciate the actual details of this issue: which |> applications are actually penalized, which are the alternatives, |> something more concrete, in other terms, that a vague reference |> to those "position" papers that we all know, in other terms ;) |> (and one of those I'd like to discuss in detail...) Maybe James |> can help here. I'm not sure what sort of help you are looking for. I thought that I very clearly pointed out the problem, and the point in the code where it occured. In typicaly code, the problem occurs mainly with configuration variables; they are declared non-const, because they have to be set on start up, either from the command line, or from a configuration file, and then used as if they were const. According to Posix, I should be able to access such variables without additional, user defined synchronization. Note that the problem can be very, very subtle, and that most of the time, the program will work despite the problem -- this is one of the most pernicious cases of undefined behavior. |> In practice, we could, for instance, *within the |> current ABI*, provide a switch to disable completely reference |> counting, would that be appreciated? It would help. But an implementation designed with reference counting in mind is likely to be rather slow when reference counting is turned off. IMHO, correct and slow is better than the current situation, but not all compiler users agree. |> I can implement this very |> quickly but I'd like to have some evidence that a non-trivial |> number of users would appreciate that short-term solution. That |> would be indeed, a short term solution, because a library |> relying purely on a non-refcounted string has subtle issues with |> memory allocation during exceptions, that definitely we don't |> want in a long term solution: if nobody has got a better idea, |> I'm afraid we have to implement also a separate ref-counted |> mini-string for usage in exceptions. Most other implementations I'm aware of don't use std::string in exceptions. That would seem to be the best solution. Other than that, there is no perfect solution with regards to exceptions. If an exception requires resources, and they aren't there, there's going to be a problem. What happens if you can't allocate the memory for the exception itself? -- James Kanze "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 10:59 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> > I'm not sure what sort of help you are looking for. I thought |> > that I very clearly pointed out the problem, and the point in |> > the code where it occured. |> Ok, my message was not clear. I'm looking for help about the |> *performance* issue, not the correctness issue. To your best |> knowledge all those users that avoid v3 basic_string for MT |> applications do that for performance or for correctness (wrt |> the Posix issue that you are pointing out in detail)?? To the best of my knowledge, not very many people avoid basic_string. Most people aren't that aware of threading issues to begin with, and most people just use whatever is there, and suppose that it meets whatever standards are usual for thread-safety on the platform in question. I only started being more wary myself because on two occasions, I've had to "fix" programs which didn't work, because they used the basic_string which came with 2.95.2 -- it just didn't occur to the authors to ask the question whether the library gave the Posix guarantees. The situation with the current library is simple: there is a specific sequence of events which will cause it to use deleted memory, double delete, etc. For that to occur, one thread must access the same object via [], at(), begin() or end(), a second thread must copy the object, and the second thread must interrupt the first thread between the test whether the object is shared, and the moment it is marked as leaked. On a typical machine, that last condition will only last a couple of machine instructions, less than a microsecond. Which means that most of the time, even if the code is incorrect, it will seem to work. And every once in a blue moon, the user will get an unexplicable crash, that the developers cannot duplicate. The problem can be avoided. The easiest (and surest) way is by synchronizing manually; only accessing the global objects to copy them (using the copy constructor) should work as well. (As soon as the representation is shared, the code works. At least in practice on single processor machines; there are no memory barriers around the non-modifying reads, nor around the write of -1 to mark the representation as leaked, which means that some updates may not be correctly seen by threads running on a different processor. Only using copies still works, however; the thread which makes the copy will at least see its update, which results in a reference count greater than 0, which is all that is needed to trigger the deep copy before leaking. Still, it's pretty shaky, and I would have expected anyone familiar with thread safety issues to have ensured that the normal memory barriers were present.) |> Reading |> those papers that I mentioned before (+ another one on C/C++ |> Users Journal which exactly touches *your* issue) it's *not* |> at all clear that the latter is the main issue, in the general |> understanding. I'm not too sure which papers you are referring to, even after Herb Sutter's name was mentionned. I do know that the one article I have read by Herb which concerned thread safety was full of errors, and resulted in a long discussion in comp.lang.c++.moderated. |> > It would help. But an implementation designed with reference |> > counting in mind is likely to be rather slow when reference |> > counting is turned off. IMHO, correct and slow is better than |> > the current situation, but not all compiler users agree. |> Indeed. Of course I'm talking about a *switch* (off by default) |> But, about the correctness point... |> > Most other implementations I'm aware of don't use std::string in |> > exceptions. That would seem to be the best solution. |> Ok, but I don't think we can also change that in the short term |> and not affecting the ABI, we are definitely going to do that in |> v7-branch and I would appreciate if you could advise about the |> best solution among all those proposed (see the thread). |> Returning to our issue, however, do you still believe that a |> switch turning off RC would be useful if we don't change the |> treatment of exceptions? I don't know, maybe we can have |> something simple for that within the present ABI, but I cannot |> make promises and want to have an idea of the amount of work. I'm not sure. As I said, the biggest part of the problem is that people aren't aware of the problem. When it comes down to it, it's not nice, the the necessary work-arounds exist. If there is a new implementation in the pipeline which doesn't have the problem, then I'd probably settle for a couple of prominent warnings, in bold face, in the d
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 15:57 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> > "This message, including any attachments may contain confidential and |> > privileged material; it is intended only for the person to whom it is |> ... |> Can you stop attaching this message to the email messages since |> it is wrong and not really valid for any open mailing list? Regretfully no. For reasons beyond my fathoming, we have to use Lotus Notes on a Windows machine for all external email, and they've set up the Notes server to add this trailer (which as you correctly point out, doesn't make much sense in a lot of contexts.) It's particularly painful, because there is no development environment on the Windows machine, so I have to ftp any code samples to and from the Solaris boxes. Next time, I'll wait until I'm at home to report an error; my Linux box doesn't have any of these problems:-). (To be fair, Windows doesn't have to be this bad, either; I've worked in places where it was actually usable.) -- James Kanze "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-04 09:14 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> >|> Secondly, it is clear that your bug report is hypothetical. The |> >|> library maintainers do not typically deal in hypotheticals. |> > I guess it is really a question of whether you want quality or |> > not. In general, all code is supposed incorrect until proven |> > otherwise -- in the case of threading issues, this is |> > particularly important, because of the random factors involved. |> Of course, we want quality (and we want performance) which is |> why we insist upon non-hypothetical bug reports (either way, |> I've already explained what is wrong with your posted code |> w.r.t. the cited FAQ entry) I know what was wrong with my code with regards to the FAQ. I know that the code didn't conform to *your* threading model. My point is that your threading model is, in a certain sense, wrong. It isn't what people expect, at least not people who are familiar with the Posix threading model. The documentation is in fact very misleading, with phrases like "like for any other shared resource", when you don't need external synchronization for other shared resources, *unless* someone is actively modifying it. Now, I'm not saying that the Posix model is the only legitimate one. But it is the one I, and most people working on Unix platforms, are familiar with, and expect. And it is a standard on those platforms. You can choose to ignore it, and to ignore what SGI has done in this regard. But in that case, you have to be aware that you are trying to create an island, in which you are different from everyone else. |> and why we insist that library users |> must write correct locking sequences outside the context of the |> library. As you well know, there is nothing in POSIX which |> dictates that a library internalize the locking vs. implying |> that the user code must hold a mutex lock. Posix only defines its own functions (most of which are either thread-safe, or have a thread-safe variant), and it only defines a binding for C for them. Other than that, we are left with general, language neutral statements like the one I quoted. Obviously, a library not specified by Posix can do what ever it wants. In practice, however, user expectations are based on what Posix does, and that leaves two alteratives: -- Model your library on the actual Posix functions, with full internal locking -- I can call write on the same file descriptor from two different threads, for example, without problems. A lot of people (although none of the experts I know) seem to expect this. Rogue Wave tries to do it, for example. IMHO, however, it isn't reasonable for a library which lets references (in the general sense) escape to the user -- Posix itself makes an exception for functions which return pointers to internal data structures. (It doesn't use those words, but if you look at the list of functions which are not guaranteed thread-safe, it includes exactly those functions, and no others.) -- Base your model on the general, language neutral statements. This is what SGI does, for example. The general statement is that I need a lock if more than one thread is accessing the "memory", and any thread is modifying it. Since the abstraction model of C++ prevents me from actually seeing the memory, one is lead to exterpolate "memory" to "object". This seems a reasonable interpretation to me. At least some experts agree -- the authors of the the SGI threading model, for example. (I consider the people who were working at SGI when that model was defined to be among the best threading experts in the world. That's just my opinion, but every time I've had a discussion with them, I've come out knowing more than when I went in.) You can, obviously, take the position that you have defined the threading model you wish to use, that you know better than everyone else, and that your decisions cannot be questioned. And I can take the position that you're just wrong, you don't know anything about threading, that g++ is worthless in a multithreaded environment, and publicize that opinion in various newsgroups. Such attitudes won't help either of us, however. This bug report came about because of a discussion in a news group. Basically, I said to watch out for std::string with g++ if you are in a multithreaded environment. I don't remember my exact words, but I'm pretty sure that the gist would have been that the g++ implementation of std::string does not behave as one might expect. I said it in a newsgroup, rather than making a bug report, because I knew of the text in the FAQ (o
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-04 12:46 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string |> [...] |> | This bug report came about because of a discussion in a news |> | group. Basically, I said to watch out for std::string with g++ |> | if you are in a multithreaded environment. I don't remember my |> | exact words, but I'm pretty sure that the gist would have been |> | that the g++ implementation of std::string does not behave as |> | one might expect. I said it in a newsgroup, rather than making |> | a bug report, because I knew of the text in the FAQ (or |> | something similar), and I was convinced that no one here would |> | consider it an error. Gaby suggested otherwise; that if I could |> | describe a case where the code could fail, although no thread |> | modified the string, I should report it as a bug. So we're |> | here, and I'm getting hounded because my email contains trailers |> | which I can do nothing about:-). I was inordinately pleased by |> James -- |> I think you can abstract over the remark about your mailer, however |> annoying it is :-) I did put a smiley behind the complaint. I can imagine that all that garbage that gets added is as annoying to others as my being told to do something about it is to me. All I can say is that it annoys me too, and that I"d get rid of it if I could. |> As of the model behind the implementation of std::string, I do not |> think we have reached an agreement within the maintainers that it is |> actually right and your description is wrong. I'm of the opinion |> that we're reached a point where it causes so much conofusion that |> there must be something wrong with it. Having listening to either |> sides and looking at the codes, I'm inclined to consider your report |> valid -- however "hypothetical" my fellow maintainers may consider |> it :-) Concurrent read accesses should be guaranted, following POSIX. All I really ask is that the problem be recognized. As I said, it only affects certain specific cases, and there are acceptable work arounds. If the doc says explicitly, we're doing something different here, I can live with that -- I would suppose that there were some good technical reasons (or possibly non-technical -- the world isn't 100% controlled by technology yet) for it. Responses along the lines of "it's only hypothetical", or "you're not playing the game according to our rules", are not helpful. They're not helpful because I know that already. The window of vulnerability is exceedingly small, which means that creating a test case which reliably fails is exceedingly difficult. From your comments in the newsgroup, I was fairly sure that you would accept my next best approach. From what I know of the extremely high technical competence of the other g++ developers, including the original author of std::string, I rather thought that they would, too. I'll admit that the "hypothetical" bit surprised me. The fact that I am not playing according to the official rules is another issue -- I know that, too, but I feel 1) that the official rules aren't really the best with regards to usability, and above all, 2) the way they are formulated is somewhat "ingenious". Point 1 is, of course, personal opinion, but the fact that some experts are also led astray by the formulation is IMHO worth considering as a problem in itself. |> This is not because you're threatening to woersen g++'s reputation |> or disregard it in production use -- if it were that, I would not |> worry ;-). That's because you know that the competition is Sun CC (which is no competition at all), and that I don't get to choose the compiler anyway:-). Seriously, however, I think you understand why I might feel obligated in certain contexts to mention the fact that g++ does have problems with regards to threading. Not problems like pre 3.0 had, of course, but the fact is that it doesn't always conform to the local conventions. Sometimes, for some very good reasons, but differences have to be doubly documented, because people don't expect them. |> This is because no matter what we might say in our FAQ, |> if the behaviour is odd enough or singular enough, it entails Fear, |> Uncertainty and Doubt. That is not what we want. I think that's the key. People should feel at ease with the tool. Globally, I like g++ -- it's become my preferred compiler for most things. Which just makes me more upset about any weaknesses. (Like the absence of export, for example:-).) -- James Kanze "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed.
[Bug c++/19249] abstract classes should not access virtually inherited class constructor
--- Additional Comments From jkanze at cheuvreux dot com 2005-01-05 14:29 --- The context of the quote from the standard is: "If the constructor of the most derived class does not specify a mem-initializer for the virtual base class V ...". In the code submitted, the constructor of the most derived class DOES specify a mem-initializer, so none of what follows applies. I think that there is a bit of history at play here. All compilers I know reject the code, I suspect because CFront rejected it, and nobody noticed that CFront was in error here. Note that the absence of a default initializer, when it is required, is undefined behavior, so a trivial fix would be to replace the call to the (non-existing) constructor in the in-charge constructor with a call to a function which displays an error message and calls abort. A better fix would be to not generate the in-charge constructor at all, resulting in a linker error if the class was ever instantiated. (Not possible here, since the class is abstract, but possible in the more general case.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19249
[Bug c++/19620] New: exception not caught when passing through C code
When an exception is thrown, terminate is called, even though
there is an appropriate handler, if there is any C code between
the exception and the handler. This is a serious problem because
a lot of third party software uses a C ABI and callbacks.
(Note that this works with Sun CC.)
-- main.cc
#include
#include
#include
extern "C"
{
extern void enrollCallback( void (*pf)() ) ;
extern void doCallback() ;
}
void
f()
{
throw std::runtime_error( "Just a test" ) ;
}
extern "C" void callback()
{
f() ;
}
int
main()
{
enrollCallback( &callback ) ;
try {
doCallback() ;
} catch ( std::exception const& error ) {
std::cout << "Exception caught: " << error.what() << std::endl ;
} catch ( ... ) {
std::cout << "Unknown exception caught" << std::endl ;
}
return 0 ;
}
test.c ---
static void (*pf)() ;
void
enrollCallback( void (*cb)() )
{
pf = cb ;
}
void
doCallback()
{
(*pf)() ;
}
-- end sources ---
Desired behavior: Program outputs:
> Exception caught: Just a test
when run. (This is the behavior of Sun CC.)
Actual behavior: terminate is called.
--
Summary: exception not caught when passing through C code
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkanze at cheuvreux dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19620
[Bug c++/19620] exception not caught when passing through C code
--- Additional Comments From jkanze at cheuvreux dot com 2005-01-31 09:55 --- Subject: Re: exception not caught when passing through C code > This is documented somewhere in the docs, I think. If you mix C > codes with C++ and exceptions are raised (through callbacks) and > you need exceptions to smoothly travel across language > boundaries, you need to compile the C code with -fexceptions. The problem is that you don't always have the sources for the C code. Most of the time, it is in some third party library for which you only have the .h's and the .a (or .so). (And the third party library has likely been compiled with Sun's cc, not gcc.) I'll admit that I don't understand the problem, at least on Sparc. There is an ABI which defines what the C stack looks like; the C++ stack is, in fact, identical. Walking back the stack is trivial. The only thing you need the tables for is for finding destructor or handler code. So you won't find them in the C code which doesn't have the tables; that's no problem, because I'm pretty sure that the C code doesn't have any destructors, nor any exception handlers. Is there something linked with portability which precludes this approach. (I know that the stack walkback code is NOT portable. But I would have thought that this was true with or without the tables.) -- James KanzeGABI Software mailto: [EMAIL PROTECTED] Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19620
