Zeta-Puppis.com

I am devel­op­ing a new web­site for a club I’m found­ing. I can’t tell you what this club will do (also because I don’t really know, yet) but the site is going to become a chal­lenge.
I wanted to use all the latest, inno­v­a­tive tech­nolo­gies around here. So, I just took PHP, Javascript, XHTML (strictly 1.0 strict!) and a MySQL data­base in my gun­ny­sack and gone around with them.

There’s an issue I’ve been facing against that just got me crazy: if I include a HTML page (not really, a php gen­er­ated one to be pre­cise) through inner­HTML the con­tent that was into the <script>...</script> tags was not exe­cuted. After some google-​ing, I found that this is a secu­rity imple­men­ta­tion: browsers doesn’t allow code to be exe­cuted into a inner­HTML block. If you break a moment and think about it, it makes per­fectly sense, but I need of such a fea­ture so I had to found a workaround.

The idea was this: let threat the html page as an xml file (although it is really one), so let use the DOM to browse it look­ing for <script></script>, then pass its con­tent to eval().
I was not using any AJAX library, so I had to wrote all the code by myself. Here is a snippet:

function execJS(node) {
       var bSaf = (navigator.userAgent.indexOf('Safari') != -1);
       var bOpera = (navigator.userAgent.indexOf('Opera') != -1);
       var bMoz = (navigator.appName == 'Netscape');

var st = node.getElementsByTagName('SCRIPT');
       var strExec;

for(var i=0;i<st.length; i++) {
               if (bSaf) {
                       strExec = st[i].innerHTML;
               } else if (bOpera) {
                       strExec = st[i].text;
               } else if (bMoz) {
                       strExec = st[i].textContent;
               } else {
                       strExec = st[i].text;
               }

try {
                       eval(strExec);
               } catch(e) {
                       alert(e);
               }
       }
}

function handlePageChanging()
{
       if (http.readyState == 4) {
               var cnt_big = document.getElementById('cnt_big');
               cnt_big.innerHTML = http.responseText;

execJS(cnt_big);
               hideLoading();
               doLinks();
       }
}

function changeContentPage(param)
{
       _current = param;

var url = param + '&aJ=y';
       showLoading();
       http.open("GET", url, true);
       http.onreadystatechange = handlePageChanging;
       http.send(null);
}

Of course you can’t copy and paste this code except the execJS func­tion (since it is this post’s pur­pose) but the impor­tant thing is that you notice how it works. Prat­i­cally, the page makes an AJAX request with changeContentPage(), then handle it through handlePageChanging(). So when we’re going to set up the con­tent with inner­HTML, we call execJS() so it will eval()-ize all the <script></script> contents.

Update: see this http://​krat​code.​blogspot.​com/​2​0​0​6​/​0​3​/​j​a​v​a​s​c​r​i​p​t​-​s​c​r​i​p​t​-​e​x​e​c​u​t​i​o​n​-​i​n​.html

If we talk about gcc exten­sions then prob­a­bly we shouldn’t talk about likely/unlikely func­tions. But since they are widely used into the GNU/Linux kernel, they are much more than strictly related.
In the truth, they are not func­tions, but macros. Let see how they’re defined:

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

You can see these lines in include/linux/compiler.h into your kernel sources. As you can see, likely and unlikely are just macros, the real gcc exten­sion is __builtin_expect.

Prat­i­cally talk­ing, __builtin_expect is a way to say to gcc that such con­di­tion is easier to happen then another (this is usu­ally called branch pre­dic­tion) and is needed to opti­mize the code (a jump, or better, an IP change­ment, takes a lot of cpu cycles, so if you can, opti­mize it).
With 1 we say that the if branch is more prob­a­ble than the else one. While, on the other side, with 0 we say that the else branch is more prob­a­ble than the if one.
That said, this means that if we know that an if (or an else) is much more prob­a­ble to happen, we should use such macro.

Please note that we’re talk­ing about kernel code that needs to be extremely opti­mized. If you’re writ­ing your own appli­ca­tion you prob­a­bly won’t need to use such exten­sions since rarely you’ll have to do branch pre­dic­tion (better, the com­piler should do this for you).