On 09/26/2012 04:00 PM, Sergey Senozhatsky wrote:
On (09/27/12 00:09), Magnus Fromreide wrote:
That they fail to throw exceptions from new is no reason to disable
set_new_handler, the newhandler is called by the runtime on out of memory
and is intended to allow the user to try fixing the issue. This is true for
the noexcept version as well. Is this yet another incompatibility?
right. the funny thing is, guess what, gcc actually has "#ifdef __EXCEPTIONS"
within operator new()
44 _GLIBCXX_WEAK_DEFINITION void *
45 operator new (std::size_t sz) _GLIBCXX_THROW (std::bad_alloc)
46 {
47 void *p;
48
49 /* malloc (0) is unpredictable; avoid it. */
50 if (sz == 0)
51 sz = 1;
52 p = (void *) malloc (sz);
53 while (p == 0)
54 {
55 new_handler handler = __new_handler;
56 if (! handler)
57 #ifdef __EXCEPTIONS
58 throw bad_alloc();
59 #else
60 std::abort();
61 #endif
62 handler ();
63 p = (void *) malloc (sz);
64 }
65
66 return p;
67 }
It tourned out, that __EXCEPTIONS with us (for operator new and STL) since 2001
"2001-02-15 Benjamin Kosnik <b...@redhat.com>"
So, I guess this is how Google has came up with the idea of C++ w/o exceptions.
Wow.
-ss
Well to be fair, not that I agree any-more, but years ago it was common
practice to disable exceptions (via the compiler) for C++ in very
specialized "REAL" "Embedded Systems". This practice was problematic in
that you needed to have a will defined Error handling design, but saved
space. Honestly, its been a long time since I worked on anything that
has a "REAL" size requirement, so I don't see the point. On the other
hand in some Embedded system The whole reason to using your own error
handling design was that in a real embedded system, design
considerations like, uptime, failure control and ability to eliminate
undefined behaviour were KEY. So taking the time to design was already a
given, and size was not a single point factor. (not arguing the C vs C++
point here BTW) So for what ever reason the decision to use C++ happens
for an embedded project. Problem was C++ exception were good for insure
the program didn't fail, but detailed failure handling became
problematic. Sure you could avoid general failures but often especially
in an embedded system you found yourself with undefined behaviour that
was nearly imposable to handle. OK in general history over :)
Unfortunately this practice has been inherited still today in segments
of other then embedded. Most commonly you may see this practice in
specialized segments like gaming consoles. Such practices are still in
valid use in such device as switches, telecommunications, avionic
systems, weapon systems, medical devices, ect.
So I have an understanding of the issues, "some" of its history, and
valid uses. But in my opinion this is still a bad implementation for
anyone distributing a general operating system.
+/* define stubs for C++ exception handling */
+#define try if (true)
+#define catch(x) if (false)
If you should do this then I think it should be spelled
#define try if (true)
#define catch else if (false)
in order to not break
if (condition)
try {
} catch(type variable) {
}
but it still breaks the syntax for it which can be shown by simply adding an
else clause to the if statement.
Oh, and furthermore I consider that Android needs a C++ compiler.
+
+/* Define __NR_perf_event_open if not already defined */
+#if __arm__
+#ifndef __NR_perf_event_open
+#define __NR_perf_event_open 364
+#endif
+#endif
+
+/*
+ * bionic libc mbstowcs version returns zero when max parameter
+ * is zero, resulting infinite loops in powertop source. Add
+ * mbstowcs wrapper to fix it.
+ */
+namespace pandroid {
+ extern "C" inline size_t mbstowcs(wchar_t *dst,
+ const char *src, size_t len)
+ {
+ return ::mbstowcs(dst, src, ::strlen(src));
+ }
+}
+
+#define mbstowcs(dst, src, len) pandroid::mbstowcs(dst, src,
len)
Still broken.
If dst isn't a NULL pointer then len is the limit on the length of the
destination buffer. In throwing away this you open up for stack smashing
attacks.
_______________________________________________
PowerTop mailing list
power...@lists.01.org
https://lists.01.org/mailman/listinfo/powertop
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
