Older blog entries for redi (starting at number 247)

recentlog seems to stop rendering after the <iframe> in bagder's post, I'm not sure why

17 Jul 2011 (updated 17 Jul 2011 at 19:50 UTC) »
badvogato, you say that confusedtrust may have fixed your problem (and I assume that's why you certified them.) If the problem you refer to is the diary entry from sness which broke recentlog, sness fixed that problem because I emailed him and pointed out the problem. confusedtrust is probably a spammer.

You've also certified r7379062259, whose "homepage" is a blog which plagiarises an essay on the history of C, which appears to originate at jakeo.com, He also plagiarises a tutorial on variables in C which possibly originates at cprogramming.com (although that could be plagiarised too). I haven't checked but I'd bet bread that every "blog" is stolen from someone else. That user is almost certainly a spammer, at the least a plagiarist. All spammers must die, be more vigilant!

Everyone else, if you think they're spammers please flag their accounts before badvogato's cerification validates them as real users.
Watch for Spammers, people. Be vigilant. The recentspam problem has been getting worse, I wonder if the spamming tool robogato discovered has been updated to use POST for new accounts.

All spammers must die.

Lots of recentspam today - you know what to do.

I need to learn to stop reading any comments on LWN that mention C++ or I'm going to get facepalm-related RSI.

3 Jun 2011 (updated 3 Jun 2011 at 17:30 UTC) »
robogato, unfortunately the diary edit page uses GET, so your changes mean I can't edit diary entries

Edit: editing works again now, like this. Thanks!

It also seems the new parser doesn't recognise <person> or <proj> tags

Edit2: I occasionally still use <proj> tags as a shortcut, but I stopped using <person> tags years ago as I find it more useful to link to a specific diary entry when responding to something in recentlog, so use <a> for a direct link to the diary entry. I think I wrote years ago that a <diary key=33>robogato<diary> would be nice :)
5 May 2011 (updated 5 May 2011 at 18:47 UTC) »

If your project mailing list receives an offer to translate your docs to "Belorussian" (aka Belarusian) from Bohdan Zograf, asking only that you link to his "blog" containing the translation, please ignore it.

His "translations" are always hosted on dodgy sites such as webhostinggeeks dot com, webhostingnet dot com and other free hosting sites, never in the same place twice, and not belonging to any blog, despite the claims in the email.

The text of the translations is always identical to the output of using Google Translate on the original English document (with all the same grammatical errors) so users would be better off just using Google Translate on the original site.

My guess is that Bohdan Zograf (sometimes the emails use other names, and come from a variety of email accounts) is trying to build a link farm with links to it from the websites of several open source projects, for the purposes of spamdexing. I expect that once there are enough of the "translation" pages linked to by unwitting webmasters who are grateful to have a translation of their content, the content will be switched for something nefarious.

You have been warned.

All spammers must die.

karlberry, thanks for the link to It's All Text!, that might be the solution to advogato's infuriatingly small textarea which insists on wrapping things at the worst possible place and breaking URLs across lines
5 Apr 2011 (updated 3 Jan 2013 at 17:50 UTC) »

[Update: see An even simpler recipe for building GCC for ... yeah, an even simpler recipe for building GCC]

A simple recipe for building GCC

Building GCC is not trivial, but is not difficult if you follow the instructions carefully.

Many people rush into trying to build it without reading the installation docs properly and make one or more of these common mistakes:

1) do not run ./configure - this is not supported, you need to run configure from outside the source directory

2) if GCC links dynamically to the prerequisite libs (GMP/MPFR/MPC) then the shared libraries must be in the dynamic linker's path, both when building gcc and when using the installed compiler.

These problems are easily avoided by reading http://gcc.gnu.org/install/prerequisites.html, http://gcc.gnu.org/install/configure.html, http://gcc.gnu.org/wiki/FAQ#configure and http://gcc.gnu.org/wiki/FAQ#configure_suffix but noone does that.

For the impatient or RTFM-intolerant, a foolproof recipe for building GCC is given below.

The trick to this recipe is that the GMP, MPFR and MPC prerequisites are not installed separately, they are built as part of gcc and linked to statically. This avoids the common problem of installing the shared libraries in a non-standard location and having to tell the dynamic linker how to find them. This method is documented at http://gcc.gnu.org/install/prerequisites.html and is much easier than building and installing the prerequisites separately, but everyone seems to choose the hard way.


If you decide to stray from this recipe without reading the docs do not be surprised if you get indigestion.

* Ingredients:

1 gcc source package (e.g. gcc-4.6.0.tar.gz)

Alternatively, download individual packages for each GCC language front end (e.g. gcc-core, gcc-g++ etc.)

1 gmp source package (e.g. gmp-5.0.1.tar.gz)

1 mpfr source package (e.g. mpfr-3.0.1.tar.gz)

1 mpc source package (e.g. mpc-0.8.1.tar.gz)

* Method:

First prepare your environment, season these variables to taste:

# the versions you will build

# where you put the downloaded source packages

# where you will build gcc

# where you want to install gcc

# the languages you want gcc to support

Create a new directory on a disk with plenty of space and unpack the sources there:

mkdir ${rootdir}
cd ${rootdir}
tar xzf ${pkgdir}/gcc-${gccver}.tar.gz
tar xzf ${pkgdir}/gmp-${gmpver}.tar.gz
tar xzf ${pkgdir}/mpfr-${mpfrver}.tar.gz
tar xzf ${pkgdir}/mpc-${mpcver}.tar.gz

Next, move the prerequisite sources into the gcc source directory:

mv gmp-${gmpver} gcc-${gccver}/gmp
mv mpfr-${mpfrver} gcc-${gccver}/mpfr
mv mpc-${mpcver} gcc-${gccver}/mpc

Now create a build directory and change to it

mkdir objdir
cd objdir

Now configure gcc:

${rootdir}/gcc-${gccver}/configure --prefix=${prefix}

Now build gcc:


Finally, install gcc:

make install

Your compiler is now ready to use.
If something goes wrong you can just remove the entire $rootdir/objdir directory and recreate it and run configure again. The source dir will be unchanged because it is never altered when you build in a separate dir.
5 Apr 2011 (updated 29 Nov 2011 at 12:01 UTC) »

Today I tried recompiling a fairly large codebase using GCC
4.6 and -std=c++0x (and also -std=gnu++0x). Due to a couple
of small bugs I was using 4.6.0 plus two patches that will
included in the 4.6.1 release. For the purpose of this
exercise, GCC 4.6 is pretty close to implementing the C++0x
rules in the FDIS that was voted for at last week's
committee meeting (there are several C++0x features such as
inheriting constructors and ref-qualifiers for member
functions which are not implemented in GCC yet, but those
features are new in C++0x and so aren't used in C++03

The results were very positive. Apart from adding a few
missing headers (which should have been there anyway)
only a couple of
changes needed to make the C++03 code also valid for

Narrowing conversions

I had to change some initializers to avoid narrowing
conversion (such as double to int, int to char) which are
allowed in C++0x. e.g

struct S {
int i;
S s = { 0.0 }; // should be { 0 }
for (int i=0; i < 10; ++i) {
char s[2] = { '0'+i }; // should be { char('0'+i) }


The definition of the function template
std::make_pair has changed in C++0x, but I was
surprised to find this caused a problem. In C++03 it's very

template<typename T1, typename T2>
make_pair(T1 x, T2 y);

The function deduces the types of its arguments and returns
a pair with those types. This saves you from
explicitly specifying the types, as shown by this example in
the standard:

In place of:

  return pair<int, double>(5,
// explicit types

a C++ program may contain:

  return make_pair(5, 3.1415926);// types are deduced

Simple, eh? Using make_pair is convenient, but
that's all it is, a convenience
function to save a bit of typing. It therefore makes no
sense to explicitly specify the types:

  return make_pair<int, double>(5,
// explicit types

This requires typing five more characters ("make_") than
just constructing a pair directly. It's pointless.
It takes the convenience function and then uses it
inconveniently. It's like putting a stepladder in front of a
high shelf, then standing next to the ladder and reaching
over it. You're doing it wrong!

Yet I found a few cases where that's exactly what had
written. And other members of the BSI C++ panel have
reported that it's used in their codebases too.

Why does it matter? Well in C++0x the definition has

template<typename T1, typename T2>
make_pair(T1&& x, T2&& y);

The template arguments of the returned pair are not
the same as the template arguments of make_pair
(they might be the same in some cases, but all.) As you may
be able to guess from the && decoration,
this was
done to support move semantics, so that the elements of the
returned pair can be move constructed (instead of
copy constructed) when the arguments are rvalues (i.e.

This means that if you disable argument deduction by
providing an explicit template argument list in C++0x, then
the function can only be called if the function arguments
are compatible with the explicit template argument types:
only rvalues arguments will be accepted if you call
make_pair<T1,T2> and only lvalues will be
accepted if you call make_pair<T1&,T2&>
because lvalues can't bind to rvalue-references and
rvalues can't bind to non-const lvalue references.

The solution? Don't call make_pair with
template arguments.

To be honest, there is one valid reason to give an
template argument list, which is if you want one type to be
explicitly specified and one to be deduced e.g.
return make_pair<const long>(0, x);

That could be useful to insert into a std::map.
If you really want the old C++03 semantics of
make_pair then you can write your own, as it's
really trivial. Whereas the semantics of the new C++0x
version are subtler and harder to get right, so I think it's
right that the standard library provides the complicated one
and that you have to define the simple one yourself (if you
even need it.)

fzort, here's a better response from a linguist in my family, my guess was probably wrong :)

I think it's an evolution such as takes place in any language in different ways. In English, I suspect this particular one comes from the mix of different other-language speakers learning English and the habit has spread because of modern media diffusion.

It is interstingly not a complete evolution. With two prepositions involved, it was originally 'tell it to me', just as it still is 'explain it to me'. The incompleteness can be felt/seen if you say something like 'I told him it'. There's a slightly clumsy feel, to me at least, in the use of the two pronouns side by side.

Consider also that English is unusual in having two words for what is often only one in other languages - to say and to tell, for dire in French. You wouldn't say 'Say it me' or 'Say me it'. Equally, the indirect object//dative case form applies to speak/talk//parler. 'Speak French to him', or 'talk sense to me' are the ways we say it. Not 'talk me sense' or 'speak him French'. So it is 'tell' that seems to have undergone this semi-evolution, why I cannot be sure. Or really I haven't a clue. But it doesn't have nowt to do with Latin vs Germanic etymology.

238 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!