Thread: [Stlport-devel] exceptions
Brought to you by:
complement
From: Petr O. <pt...@is...> - 2007-05-16 06:00:05
|
+ * stlport/stl/_stdexcept_base.h, _stdexcept_base.c: __Names_exception + do not truncate anymore exception message when longer than internal + static buffer, a dynamic buffer is allocated through malloc in this + case. I haven't use __iostring class in this case as it would + have introduce a cyclic dependency between classes. +__Named_exception::__Named_exception(const string& __str) { + size_t __size = strlen(__get_c_string(__str)) + 1; + if (__size > _S_bufsize) { + _M_name = (char*)malloc(__size * sizeof(char)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + if (_M_name == 0) { + __size = _S_bufsize; + _M_name = _M_static_name; + } + } + else { + _M_name = _M_static_name; + } Well, and what about bad_alloc and exception due to memory limits? IMO no dynamic allocation should happen during exception generation. - ptr |
From: Ulrich E. <eck...@sa...> - 2007-05-16 09:23:10
|
On Wednesday 16 May 2007 07:59, Petr Ovtchenkov wrote: > + * stlport/stl/_stdexcept_base.h, _stdexcept_base.c: > __Names_exception + do not truncate anymore exception message when > longer than internal + static buffer, a dynamic buffer is allocated > through malloc in this + case. I haven't use __iostring class in th= is > case as it would + have introduce a cyclic dependency between > classes. > > > +__Named_exception::__Named_exception(const string& __str) { > + size_t __size =3D strlen(__get_c_string(__str)) + 1; > + if (__size > _S_bufsize) { > + _M_name =3D (char*)malloc(__size * sizeof(char)); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + if (_M_name =3D=3D 0) { > + __size =3D _S_bufsize; > + _M_name =3D _M_static_name; > + } > + } > + else { > + _M_name =3D _M_static_name; > + } > > > Well, and what about bad_alloc and exception due to memory limits? bad_alloc must not use this, I absolutely agree. If other exceptions use th= is,=20 and you are already so short on memory that allocation fails, it makes litt= le=20 difference if the construction of the exception causes a bad_alloc, only=20 constructing the bad_alloc must not cause an allocation failure. That said, I don't like above code either. The reason is that I throw a lon= g=20 string, and if allocation fails it silently gets truncated. My main problem= =20 with this is that there is a silent failure, I'd much rather have a bad_all= oc=20 thrown at me instead. What is the rationale for the fixed-size buffer? What= =20 is the rationale for truncating instead of signalling the allocation failur= e? Further, I'd prefer C++ casts and sizeof char is always by definition 1. > IMO no dynamic allocation should happen during exception generation. Why? bad_alloc is a special case, as it is a result of dynamic allocation=20 failure, but other exceptions can well use strings. They even have to,=20 according to the standard, like e.g. runtime_error, which carries a string. Uli --=20 Sator Laser GmbH Gesch=E4ftsf=FChrer: Ronald Boers, Amtsgericht Hamburg HR B62 932 ***************************************************************************= *********** Visit our website at <http://www.satorlaser.de/> ***************************************************************************= *********** Diese E-Mail einschlie=DFlich s=E4mtlicher Anh=E4nge ist nur f=FCr den Adre= ssaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benach= richtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf= =E4nger sein sollten. Die E-Mail ist in diesem Fall zu l=F6schen und darf w= eder gelesen, weitergeleitet, ver=F6ffentlicht oder anderweitig benutzt wer= den. E-Mails k=F6nnen durch Dritte gelesen werden und Viren sowie nichtautorisie= rte =C4nderungen enthalten. Sator Laser GmbH ist f=FCr diese Folgen nicht v= erantwortlich. ***************************************************************************= *********** |
From: <fra...@fr...> - 2007-05-16 13:58:41
|
bad_alloc do not use __Named_exception. In the most usual case, bad_alloc exception is defined by native library as it is thrown by new operator that STLport do not redefine. Even with limited native libraries having no bad_alloc, STLport own bad_alloc do not use __Named_exception as C++ Standard in 18.4.2.1 do not require a bad_alloc constructor taking a message. So this patch has no impact on bad_alloc and __Named_exception shall never be raised in an out of memory context except if a user badly return a runtime_error exception for instance in such a case which is of course bad coding practice. I intentionally use malloc in this new implementation to avoid an additional exception to be raised. See C++ Standard 15.5.1 note 134, if I throw an exception in __Named_exception constructor, terminate function will be called. I preferred to keep the original failure reason even if exception message is truncated. The reason for static buffer is historical, I had never notice it before a mail from you, Uli, saying that your message was truncated in STLport exceptions. IMO historical reason was simply to limit system calls in exception handling process which I consider as good practice, this is why I keep it. This is like the sizeof(char), do the C++ or rather C Standard really specify that it must be 1, I didn't want to check it so I simply took sizeof. I will fix change C cast. Bests Ulrich Eckhardt wrote: > On Wednesday 16 May 2007 07:59, Petr Ovtchenkov wrote: > >> + * stlport/stl/_stdexcept_base.h, _stdexcept_base.c: >> __Names_exception + do not truncate anymore exception message when >> longer than internal + static buffer, a dynamic buffer is allocated >> through malloc in this + case. I haven't use __iostring class in this >> case as it would + have introduce a cyclic dependency between >> classes. >> >> >> +__Named_exception::__Named_exception(const string& __str) { >> + size_t __size = strlen(__get_c_string(__str)) + 1; >> + if (__size > _S_bufsize) { >> + _M_name = (char*)malloc(__size * sizeof(char)); >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> + if (_M_name == 0) { >> + __size = _S_bufsize; >> + _M_name = _M_static_name; >> + } >> + } >> + else { >> + _M_name = _M_static_name; >> + } >> >> >> Well, and what about bad_alloc and exception due to memory limits? >> > > bad_alloc must not use this, I absolutely agree. If other exceptions use this, > and you are already so short on memory that allocation fails, it makes little > difference if the construction of the exception causes a bad_alloc, only > constructing the bad_alloc must not cause an allocation failure. > > That said, I don't like above code either. The reason is that I throw a long > string, and if allocation fails it silently gets truncated. My main problem > with this is that there is a silent failure, I'd much rather have a bad_alloc > thrown at me instead. What is the rationale for the fixed-size buffer? What > is the rationale for truncating instead of signalling the allocation failure? > > Further, I'd prefer C++ casts and sizeof char is always by definition 1. > > >> IMO no dynamic allocation should happen during exception generation. >> > > Why? bad_alloc is a special case, as it is a result of dynamic allocation > failure, but other exceptions can well use strings. They even have to, > according to the standard, like e.g. runtime_error, which carries a string. > > Uli > > |
From: Petr O. <pt...@is...> - 2007-05-17 04:47:07
|
On Wednesday 16 May 2007 13:24, Ulrich Eckhardt wrote: > > bad_alloc must not use this, I absolutely agree. If other exceptions use this, > and you are already so short on memory that allocation fails, it makes little > difference if the construction of the exception causes a bad_alloc, only > constructing the bad_alloc must not cause an allocation failure. > > That said, I don't like above code either. The reason is that I throw a long > string, and if allocation fails it silently gets truncated. My main problem > with this is that there is a silent failure, I'd much rather have a bad_alloc > thrown at me instead. > What is the rationale for the fixed-size buffer? All exception before ones from <stdexcept> are used fixed-size messages (and this exceptions used in case when syscalls are undesirable). The allocation within exception really possible, but this lead to problem of deallocation (or memory leak) and computational price of exceptions become much higher. > What > is the rationale for truncating instead of signalling the allocation failure? > > Further, I'd prefer C++ casts and sizeof char is always by definition 1. > > > IMO no dynamic allocation should happen during exception generation. > > Why? bad_alloc is a special case, as it is a result of dynamic allocation > failure, but other exceptions can well use strings. They even have to, > according to the standard, like e.g. runtime_error, which carries a string. > > Uli > - ptr |
From: <fra...@fr...> - 2007-05-16 14:10:53
|
Hi Petr I saw that you rollback above modif for link failure reason. Here is a link explaining how to submit bug: http://stlport.sourceforge.net/BugReport.shtml Could you follow your own rules ? I have tested this code under Windows with MSVC before commiting it. I guess you had problem under Linux, how do you want me to test it if you do not leave code in SVN. Are you really expecting SVN trunk to always be ready for a release ? Petr Ovtchenkov wrote: > + * stlport/stl/_stdexcept_base.h, _stdexcept_base.c: __Names_exception > + do not truncate anymore exception message when longer than internal > + static buffer, a dynamic buffer is allocated through malloc in this > + case. I haven't use __iostring class in this case as it would > + have introduce a cyclic dependency between classes. > > > +__Named_exception::__Named_exception(const string& __str) { > + size_t __size = strlen(__get_c_string(__str)) + 1; > + if (__size > _S_bufsize) { > + _M_name = (char*)malloc(__size * sizeof(char)); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + if (_M_name == 0) { > + __size = _S_bufsize; > + _M_name = _M_static_name; > + } > + } > + else { > + _M_name = _M_static_name; > + } > > > Well, and what about bad_alloc and exception due to memory limits? > IMO no dynamic allocation should happen during exception generation. > > - ptr > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Stlport-devel mailing list > Stl...@li... > https://lists.sourceforge.net/lists/listinfo/stlport-devel > > > |
From: Petr O. <pt...@is...> - 2007-05-17 04:33:12
|
I'm sorry for you inconveniences, but take into consideration following notes: - rollback (and apply back) modifications is NORMAL part of development, so I don't see here cause for a screaming match; - you has no plan and target of modifications, so half of you changes are surprise at least for me; chaotic modifications without final goal not impressed me and looks like coding just for coding; WBR, - ptr On Wednesday 16 May 2007 18:10, you wrote: > Hi Petr > > I saw that you rollback above modif for link failure reason. Here is a > link explaining how to submit bug: > > http://stlport.sourceforge.net/BugReport.shtml > > Could you follow your own rules ? I have tested this code under > Windows with MSVC before commiting it. I guess you had problem under > Linux, how do you want me to test it if you do not leave code in SVN. > Are you really expecting SVN trunk to always be ready for a release ? > > > Petr Ovtchenkov wrote: > > + * stlport/stl/_stdexcept_base.h, _stdexcept_base.c: __Names_exception > > + do not truncate anymore exception message when longer than internal > > + static buffer, a dynamic buffer is allocated through malloc in this > > + case. I haven't use __iostring class in this case as it would > > + have introduce a cyclic dependency between classes. > > > > > > +__Named_exception::__Named_exception(const string& __str) { > > + size_t __size = strlen(__get_c_string(__str)) + 1; > > + if (__size > _S_bufsize) { > > + _M_name = (char*)malloc(__size * sizeof(char)); > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > + if (_M_name == 0) { > > + __size = _S_bufsize; > > + _M_name = _M_static_name; > > + } > > + } > > + else { > > + _M_name = _M_static_name; > > + } > > > > > > Well, and what about bad_alloc and exception due to memory limits? > > IMO no dynamic allocation should happen during exception generation. > > > > - ptr > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Stlport-devel mailing list > > Stl...@li... > > https://lists.sourceforge.net/lists/listinfo/stlport-devel > > > > > > > > |
From: <fra...@fr...> - 2007-05-19 16:37:48
|
Petr Ovtchenkov wrote: > I'm sorry for you inconveniences, but take into consideration following notes: > > - rollback (and apply back) modifications is NORMAL part of development, so > I don't see here cause for a screaming match; > Well, it depends on the rollback reasons. I don't think that if you do a modification that break portage for DMC compiler under Windows you will accept that I rollback everything.Rollback should only take place if the whole modification is wrong and not if it introduce a small regression in trunk. Even in this case, for mutual respect, I would prefer to rollback my own modification, just send a mail next time explaining why a modification should be reverted. > - you has no plan and target of modifications, so half of you changes are > surprise at least for me; chaotic modifications without final goal not > impressed me and looks like coding just for coding; > I hope it was good surprises. My plan for STLport 5.2 is rather simple: - TR1 - localization enhancement - general enhancements - impress you :-) This modification is part of the 3rd category. I am not going to signal all modification 1 week before I do it, lets try to be a little bit pragmatic. You and everyone else has all the time necessary to signal any real issue. |