- default initialization when creating a new entry in a container - 7 Updates
- Limiting function recursion depth - 15 Updates
- Is one programming language more secure than the rest? - 3 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 25 11:57AM +0100 Does anyone know an easy way to prevent default-initialization of new elements in a container? I.e. if we'd have a vecor<int>, when I do a .resize( s ), the new elements would become initalized with int(), meaning zero. Of course I could create a class containing an int which isn't initialized in the constructor, but this is rather unhandy. |
| Thiago Adams <thiago.adams@gmail.com>: Mar 25 05:52AM -0700 On Monday, March 25, 2019 at 7:57:35 AM UTC-3, Bonita Montero wrote: > int(), meaning zero. Of course I could create a class containing an > int which isn't initialized in the constructor, but this is rather > unhandy. Check if 'reserve' solves your problem. https://en.cppreference.com/w/cpp/container/vector/reserve |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 25 01:56PM +0100 >> unhandy. > Check if 'reserve' solves your problem. > https://en.cppreference.com/w/cpp/container/vector/reserve .reserve() doesn't grow the vector so that .end() is adjusted propery. And with debug-builds the []-operator and the iterators might be bounds -checking so that a debugger might break if you access the vector beyond .end(). And I'm even mot sure if .reserve() is oblgated to really grow the capacity; I think it could do nothing in every case in an unopti- mized implementation. |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 25 03:29PM +0200 On 25.03.2019 12:57, Bonita Montero wrote: > new elements in a container? I.e. if we'd have a vecor<int>, when > I do a .resize( s ), the new elements would become initalized with > int(), meaning zero. So do not use resize(). Use push_back(), emplace_back() or range insert(), possibly after a suitable reserve(). What's your motivation to avoid zero initialization? If performance, then you should first profile your app to see if it's really a problem. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 25 08:18AM -0700 On Monday, 25 March 2019 12:57:35 UTC+2, Bonita Montero wrote: > int(), meaning zero. Of course I could create a class containing an > int which isn't initialized in the constructor, but this is rather > unhandy. Why we need uninitialized elements? Do we want to initialize those in random order? In what situation we need that? Only std::array (as aggregate) can be made with elements in uninitialized state. With std::vector it can't be done so the valid pattern is that we first reserve() and then emplace_back() the elements to it. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 25 05:06PM +0100 > Why we need uninitialized elements? If you overwrite the elements later the first initialization isn't necessary. And compilers are not smart enough to optimize away the zero-initialization. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 25 09:33AM -0700 On Monday, 25 March 2019 18:06:22 UTC+2, Bonita Montero wrote: > If you overwrite the elements later the first initialization isn't > necessary. And compilers are not smart enough to optimize away the > zero-initialization. The implied question (by parts of my answer that you erased) is why not to first reserve() and later emplace_back()? |
| El Jo <giorgio.zoppi@gmail.com>: Mar 24 04:43PM -0700 El domingo, 24 de marzo de 2019, 16:32:04 (UTC+1), Bonita Montero escribió: > almost never happen. The only case which might tigger a stack > overflow realistically is a massively misuse of alloca(). But > using alloca() is untypical for C++-programs. I disagree. I had experience of code that unfortunately was already in production where a recursive bad parser of ASN.1 for a cryptokey crashed the stack since we were in embedded enviroment. |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 25 09:07AM +0200 On 25.03.2019 0:58, Mr Flibble wrote: >> heap. > I assume you are joking based on what you write next because that is > simply bullshit. Probably you misunderstood me somehow. What I wanted to say is that certainly there are some people who would like to use deep recursive algorithms in C++. A million iteration loop is perfectly fine, so why should a million deep recursion not be? Alas, currently they can't because the stack size is pretty limited and there are no safeguards. Even if the recursion depth can be artificially bounded like in your solution, it would not be safe to go anywhere near the max stack size as there are too many uncontrollable factors affecting the stack memory usage. As you said yourself, sometimes aborting too deep recursion with an exception is acceptable, sometimes it is not. If it is not, then I cannot use a recursive solution at all, period. It just does not work. I have to rewrite my solution as non-recursive, and there would be no point to keep the recursive variant around. So that's why Bonita is not seeing deep recursive functions using up all the stack. If an exception is acceptable, then I could come closer to utilizing the whole stack, but nowhere near 100% as this would be way too dangerous, especially with a rigid compile-time constant like in your solution. To play it safe in a library used in unknown environments I would not dare to use over half of the default stack space. So again Bonita is not seeing a recursive function using up all the stack. |
| Juha Nieminen <nospam@thanks.invalid>: Mar 25 08:30AM >> overflow realistically is a massively misuse of alloca(). But >> using alloca() is untypical for C++-programs. > Nonsense. Do you have anything constructive to say? How about you explain your objection and present some arguments? --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| leigh.v.johnston@googlemail.com: Mar 25 01:33AM -0700 On Monday, March 25, 2019 at 8:30:18 AM UTC, Juha Nieminen wrote: > >> using alloca() is untypical for C++-programs. > > Nonsense. > Do you have anything constructive to say? As far as this reply is concerned whether or not I have anything constructive to say is irrelevant. > How about you explain your objection and present some arguments? How about I continue to dismiss without evidence assertions made without evidence? /Leigh |
| fir <profesor.fir@gmail.com>: Mar 25 01:38AM -0700 W dniu niedziela, 24 marca 2019 19:12:38 UTC+1 użytkownik Bonita Montero napisał: > >> _compile-time_ tempalte-parameter would be silly. > > Yet more nonsense. > Absolute no argumentation from you - impressing. the word nonesnse is not much proper here but its sorta untrue imo if some is lazy he can for example use a quicksort in stack version - stack deepnes of quicksort on most pessimistic case is about N (where N are numbers of items to sort) (and each that item has at least 4 bytes i think usually probebly more) it means that for example if someone uses this for sorting cells on a grid or something like that it would work in most cases (where this stac deepnes is lower) but will 'crash' on some rare of prepared cases the way would be not to be so lazy and revrite if on non stck version..besides (for lazy ones) if someone wants to track a recursion depth he may use one ststic integer which he would ++ and -- |
| fir <profesor.fir@gmail.com>: Mar 25 01:55AM -0700 W dniu poniedziałek, 25 marca 2019 08:07:57 UTC+1 użytkownik Paavo Helde napisał: > play it safe in a library used in unknown environments I would not dare > to use over half of the default stack space. So again Bonita is not > seeing a recursive function using up all the stack. what you say is sane but i thionk its not exactly logicaly 'strict' (tight? rigorous? - sorry or my weak english) some points are,-> 1) i think you may read the stack pointer in main at program enter and then compare to this value to gave sorta absolute stack usage counted (it may seen be as hack but sorta can be used) 2) in windows at least yu may set stack size at compile time (you may probebly stet 50 MB if you want) (it probably can be set even after compiling by hackin the exe, as it is a fireld in exe header which says what stack this exe want to hae) 3) in windows i think they coud do far more save "resizable" stack, this is becouse after stack there is unmapped page of ram and when you hit such page afair system has some exception which he utylises yo map this ram (this 'exception' could be potentially used just to reallock up whole stack, it may be even copied in another place) im not even sure if they dont do that (last checked they didnt but i guess they do or should do at least something) 4) obviously sad that c dont gives stack information at will (at leas some gcc extensions should define some functions/intrinsics like extern void* stack_top; extern void* stack_bottom; extern void* current_stack_pointer; |
| fir <profesor.fir@gmail.com>: Mar 25 02:02AM -0700 W dniu poniedziałek, 25 marca 2019 09:38:59 UTC+1 użytkownik fir napisał: > > Absolute no argumentation from you - impressing. > the word nonesnse is not much proper here but its sorta untrue imo > if some is lazy he can for example use a quicksort in stack version - stack deepnes of quicksort on most pessimistic case is about N (where N are numbers of items to sort) (and each that item has at least 4 bytes i think usually probebly more) in most optymistyic this deepnes is probably lg2(N) so for 1 milion it would be like only 20... in real cases it is somewhere between, this 20 and that prepared milion, (closer to 20 as to get that pessimistic case every entry should be prepared and chances probably drop fast...but afair there is a risk, and you may sort bigger sets of data and then risk will rise) |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 24 05:45PM +0100 > Your code is not re-entrant, ... Why? thread_local is like static but for each thread with an individual isntance. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 24 04:44PM On 24/03/2019 16:25, Scott Lurndal wrote: > Your code is not re-entrant, however. May be a limitation for some usage > (e.g. if the recursion invokes a leaf function via a function pointer or > std::function). Nonsense. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| David Brown <david.brown@hesbynett.no>: Mar 25 10:59AM +0100 > As far as this reply is concerned whether or not I have anything constructive to say is irrelevant. >> How about you explain your objection and present some arguments? > How about I continue to dismiss without evidence assertions made without evidence? How about you give some brief examples or explanation about why you think he is talking nonsense, and where you see your code being useful. Then the discussion can progress above the pantomime level. If you think your class is useful and stack overflow is a real problem, you haven't given any evidence of that either. (If you are just giving the class as an example of thread local data, RAII, or CRTP, without claiming it is useful in itself, that's fine.) |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 24 04:52PM On 24/03/2019 16:48, Bonita Montero wrote: > No, not nonsense. No one cares about stack-overflows at least in > userspace. With Windows the default stacksize is one MB and with > Linux its 2MB. No one does recursions that eat so much stack-size. More nonsense. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| scott@slp53.sl.home (Scott Lurndal): Mar 25 01:48PM >> Your code is not re-entrant, ... >Why? thread_local is like static but for >each thread with an individual isntance. I've been using thread-local data for almost three decades; Hell, I've implemented thread-local data in operating systems. I'm pretty sure I understand it quite well. The function that Flibble posted won't work as documented if it is re-entered from the same thread further down the call stack. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 25 07:58AM -0700 On Monday, 25 March 2019 15:48:45 UTC+2, Scott Lurndal wrote: > I understand it quite well. > The function that Flibble posted won't work as documented if it is re-entered > from the same thread further down the call stack. What function you mean? To re-enter function from same thread down the call stack the function has to be calling some other function(s). |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 25 05:00PM +0100 > The function that Flibble posted won't work as documented if it > is re-entered from the same thread further down the call stack. No, the idea is correct. The TLS-specific counter is incremented with each call-level for each instantiation of a new recursion _limiter and decremented on destruction / retuen. The thing is simply, that almost no one cares for stack-overflows; so his code is almost useless. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 25 09:20AM -0700 On Sunday, March 24, 2019 at 11:32:04 AM UTC-4, Bonita Montero wrote: > almost never happen. The only case which might tigger a stack > overflow realistically is a massively misuse of alloca(). But > using alloca() is untypical for C++-programs. Bonita, don't forget: Leigh's writing a new master neo-lang right? So, apparently he's running into this issue in his own neo-generated code often enough that he saw the need to create a new neo-disaster class to handle these kinds of infinite recursion issues. We'll likely see extensions added as time goes by and more neo-disasters are found. J/k, Leigh. Where's your sense of humor? -- Rick C. Hodgin |
| Juha Nieminen <nospam@thanks.invalid>: Mar 25 10:50AM https://resources.whitesourcesoftware.com/blog-whitesource/is-one-language-more-secure I'm actually honestly surprised how low C++ ranks in the amount-of-reported-vulnerabilities list. I would have guessed it would have ranked much higher (perhaps even second, after C). I love C++, but that doesn't make me blind to the ways to easily shoot yourself in the foot with it, especially with the millions of inexperienced C++ programmers out there. That's why I'm truly surprised how well C++ fares in that list. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 25 03:19PM +0200 On 25.03.2019 12:50, Juha Nieminen wrote: > I'm actually honestly surprised how low C++ ranks in the > amount-of-reported-vulnerabilities list. I would have guessed it would > have ranked much higher (perhaps even second, after C). Do not take that this report too seriously, it's basically about advertizing their company and their tools. Apparently they have not weighed those numbers by *anything*, so the results cannot be really used for comparing languages, despite the click-bait headlines. |
| David Brown <david.brown@hesbynett.no>: Mar 25 03:24PM +0100 On 25/03/2019 14:19, Paavo Helde wrote: > advertizing their company and their tools. Apparently they have not > weighed those numbers by *anything*, so the results cannot be really > used for comparing languages, despite the click-bait headlines. That was my thoughts. There is no scaling by project sizes or numbers. Do the leaps in Ruby vulnerabilities come from problems with Ruby, problems with common Ruby libraries, hoards of Ruby newbies who can't code correctly, a high growth rate for the latest fad language, or that there are now more security researchers who understand Ruby and are checking these projects? This report tells us /nothing/ of use or interest. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment