Est-ce qu'un opérateur littéral C défini par l'utilisateur de jamais être passé un pointeur NULL?

Question

Peut-C ++ opérateur littéral défini par l'utilisateur jamais passé un pointeur NULL?

Ce qui se passe réellement avec une version expérimentale de g ++ (version gcc 4.7.0 20.111.114 (expérimental) [révision du tronc 181364] (Debian 20111114-1)) mais je ne suis pas sûr si cela est un bug (90% sûr) ou un comportement attendu étrange.

Exemple de programme:

#include <iostream>
#include <stdexcept>
#include <string>

std::string operator "" _example (const char * text) {
  using std::cerr;
  using std::endl;
  cerr << "text (pointer) = " << static_cast<const void *>(text) << endl;
  if (!text) throw std::runtime_error("Is a null pointer really expected?");
  cerr << "text (string) = \"" << text << '"' << endl;
  return text;
}

int main() {
  2_example;
  1_example;
  0_example;
}

Sortie (probablement un bogue dans gcc ... mais peut-être pas, d'où la question?!):

text (pointer) = 0x8048d49
text (string) = "2"
text (pointer) = 0x8048d4b
text (string) = "1"
text (pointer) = 0
terminate called after throwing an instance of 'std::runtime_error'
  what():  Is a null pointer really expected?
Aborted

Il est non seulement "0_example"; il est à chaque fois que la valeur littérale est égale à zéro. Par exemple, il arrive encore, même si le littéral est « 0x0000_example ».

Est-ce un bug? Ou un peu étrange cas particulier lorsque la valeur du littéral est égal à zéro?

Answer 1

As Alf P. Steinbach assured me in a nice comment, this is a bug, not standard behavior (no big deal, since I was using a gcc snapshot).

I went to file a gcc bug, but it looks like it's already been filed and fixed upstream:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50958