Votre tâche: écrire un programme qui doit évidemment se terminer, mais ce n’est jamais le cas (même dans le cas d’une panne d’ordinateur). Faites en sorte qu'il semble devoir effectuer une tâche simple: ajouter des chiffres, imprimer quelque chose, ... Mais cela reste pris dans une boucle infinie.

Essayez de rendre votre programme très clair et simple, tout en restant bloqué dans une boucle imprévue. Les électeurs: jugez les réponses à quel point elles sont "sournoises"!

Concours de popularité: soyez créatif!

Javascript

var x=prompt('Enter a value under 100');
while (x != 100) {
  x=x+1;
}
console.log('End!');

prompt () renvoie une chaîne et la boucle ajoute le caractère '1', il ne sera jamais égal à 100.

C

Juste un exemple de programme de base illustrant les trois types différents de boucles while en C.

int main() {

    int x = 0;

    // Multi-statement while loops are of the form "while (condition) do { ... }" and
    // are used to execute multiple statements per loop; this is the most common form
    while (x < 10) do {
        x++;
    }

    // x is now 10

    // Null-statement while loops are of the form "while (condition) ;" and are used
    // when the expression's side effect (here, decrementing x) is all that is needed
    while (x-- > 0)
        ; // null statement

    // x is now -1

    // Single-statement while loops are of the form "while (condition) statement;"
    // and are used as a shorthand form when only a single statement is needed
    while (x > -10)
        x--;

    // x is now -10

    return 0;
}

Les boucles While n'ont pas de "faire" avant l'ouverture de l'accolade. Cela crée en fait une boucle do-while à l'intérieur de la boucle (x <10) qui se termine par la "déclaration null" suivante. Puisque x est incrémenté à l'intérieur de la boucle, puis décrémenté dans la condition de la boucle do-while, la boucle interne ne se termine jamais, pas plus que la boucle externe. La boucle "instruction unique" à la fin n'est jamais atteinte.

Si vous êtes toujours confus, regardez ici (hébergé en externe car codegolf.SE n'aime pas les blocs de code dans les spoilers).

JavaScript

var a = true;
(function() {
  while(!a){}
  alert("infinite");
  var a = true;
})();

Levage variable: JavaScript saisira ma deuxième définition de var a = true;, le déclarera en haut de la fonction var a;et modifiera mon affectation afin que sa a = true;signification asoit indéfinie au moment où il entre dans la boucle while.

C #

class Program
{
    // Expected output:
    // 20l
    // 402
    // 804
    // l608
    // 32l6
    // game over man

    static void Main()
    {
        var x = 20l;
        while (x != 6432)
        {
            Console.WriteLine(x);
            x *= 2;
        }
        Console.WriteLine("game over man");
    }
}

Le nombre littéral dans la première ligne de la fonction n'est pas un '201', mais un '20' avec un suffixe 'L' minuscule ( long datatype). Le nombre débordera assez rapidement sans jamais atteindre 6432, mais le programme continuera à moins que la vérification du débordement ne soit activée dans les options de construction.
Sensiblement, Visual Studio 2013 (et probablement d’autres versions également) vous avertissent de ce code, vous recommandant d’utiliser "L" au lieu de "l".

C

Qu'en est-il de la précision?

int main(void)
{
    double x = 0;
    while(x != 10) x += 0.1;
    return 0;
}

Imaginez que vous deviez stocker une plage de nombres entiers <0; 3> dans la mémoire de l'ordinateur. Il n'y a que 4 nombres entiers dans cette plage (0,1,2,3). Il suffit d'utiliser 2 bits pour stocker cela en mémoire. Maintenant, imaginez que vous deviez stocker une plage de nombres à virgule flottante <0; 3>. Le problème est qu’il existe un nombre infini de nombres en virgule flottante dans cette plage. Comment stocker un nombre infini de nombres? C'est impossible. Nous ne pouvons stocker qu'un nombre fini de nombres. C'est pourquoi certains nombres comme 0,1 sont en réalité différents. Dans le cas de 0.1, il est 0.100000000000000006. Il est fortement recommandé de ne pas utiliser == ou! = Dans les conditions où vous utilisez des nombres à virgule flottante.

HTML / JavaScript

Imaginez que vous avez une zone de saisie dans votre page:

<input onfocus="if (this.value === '') alert('Input is empty!');">

Et maintenant, vous voulez taper quelque chose dedans ... Essayez dans Chrome: http://jsfiddle.net/jZp4X/ .

La boîte de dialogue standard du navigateur appelée avec la alertfonction est modale. Ainsi, lorsqu'elle est affichée, le focus est retiré de la zone de texte, mais lorsqu'il est ignoré, la zone de texte reçoit le focus.

C ++

#include <iostream>
#include <cstddef>

int main() {
    size_t sum = 0;
    for (size_t i = 10; i >= 0; --i) {
         sum += i;
    }
    std::cout << sum << std::endl;
    return 0;
}

La condition i >=0est toujours vraie car size_t n'est pas signé.

frapper

(Il y avait une demande pour pas de boucles ou de récursivité)

#!/bin/bash

# Demo arrays

foo=("Can I have an array?")

echo $foo

echo ${foo[0]}

foo[2] = `yes`

echo $foo

echo ${foo[2]}

Au lieu d'attribuer la chaîne 'oui' à foo [2], cela appelle la commande système yes, qui remplit foo [2] avec une quantité infinie de "oui \ n".

C

La lettre "x" a été perdue dans un fichier. Un programme a été écrit pour le trouver:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
  FILE* fp = fopen("desert_file", "r");
  char letter;
  char missing_letter = argv[1][0];

  int found = 0;
  printf("Searching file for missing letter %c...\n", missing_letter);
  while( (letter = fgetc(fp)) != EOF ) {
    if (letter == missing_letter) found = 1;
  }
  printf("Whole file searched.\n");
  fclose(fp);
  if (found) {
    printf("Hurray, letter lost in the file is finally found!\n");
  } else {
    printf("Haven't found missing letter...\n");
  }
}

Il a été compilé et à courir et il a finalement crié:

Hurray, letter lost in the file is finally found!

Pendant de nombreuses années, les lettres ont été sauvées de cette façon jusqu'à ce que le nouveau type optimise le code. Il connaissait bien les types de données et savait qu'il valait mieux utiliser des signatures non signées que signées pour les valeurs non négatives, car cette plage est plus étendue et offre une certaine protection contre les débordements. Alors il a changé int en unsigned int . Il connaissait également suffisamment l'ascii pour savoir qu'ils avaient toujours une valeur non négative. Donc, il a également changé de caractère en caractère non signé . Il compila le code et rentra chez lui fier du bon travail qu'il accomplissait. Le programme ressemblait à ceci:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
  FILE* fp = fopen("desert_file", "r");
  unsigned char letter;
  unsigned char missing_letter = argv[1][0];

  unsigned int found = 0;
  printf("Searching file for missing letter %c...\n", missing_letter);
  while( (letter = fgetc(fp)) != EOF ) {
    if (letter == missing_letter) found = 1;
  }
  printf("Whole file searched.\n");
  fclose(fp);
  if (found) {
    printf("Hurray, letter lost in the file is finally found!\n");
  } else {
    printf("Haven't found missing letter...\n");
  }
}

Il est revenu à un désastre le lendemain. La lettre "a" était manquante et même si elle était supposée se trouver dans le "fichier_du_ désert" contenant "abc", le programme le cherchait pour toujours en imprimant:

Searching file for missing letter a...

Ils ont renvoyé le gars et sont revenus à la version précédente en se rappelant qu'il ne fallait jamais optimiser les types de données dans du code de travail.

Mais quelle est la leçon qu'ils auraient dû apprendre ici?

Tout d’abord, si vous regardez la table ascii, vous remarquerez qu’il n’ya pas de fichier EOF. En effet, EOF n'est pas un caractère mais une valeur spéciale renvoyée par fgetc (), qui peut renvoyer un caractère étendu en int ou -1 indiquant la fin du fichier.
Tant que nous utilisons un caractère signé, tout fonctionne correctement - un caractère égal à 50 est étendu par fgetc () dans un entier égal à 50 également. Ensuite, nous le transformons en caractère et avons toujours 50. Même chose pour -1 ou toute autre sortie provenant de fgetc ().
Mais regardez ce qui se passe lorsque nous utilisons des caractères non signés. Nous commençons par un caractère dans fgetc (), étendons-le à int puis souhaitons avoir un caractère non signé. Le seul problème est que nous ne pouvons pas conserver -1 dans un caractère non signé. Le programme la stocke sous la forme 255, qui n'est plus égale à EOF.

Caveat
Si vous consultez la section 3.1.2.5 Types de copie de la documentation ANSI C, vous verrez que le caractère signé ou non dépend de la mise en œuvre. Donc, le gars ne devrait probablement pas être licencié, car il a trouvé un bogue très délicat caché dans le code. Cela pourrait apparaître lors du changement de compilateur ou lors du passage à une architecture différente. Je me demande qui serait viré si le bogue venait à apparaître dans un tel cas;)

PS Le programme a été construit autour du bogue mentionné dans PC Assembly Language par Paul A. Carter

Regex

Avec les entrées appropriées, les expressions rationnelles suivantes peuvent entraîner l'encrassement de la plupart des moteurs de expressions rationnelles:

^\w+(\s*\w+)*$

Une simple entrée telle que "Programming Puzzles and Code Golf Stack Exchange - Mozilla Firefox"ou "AVerySimpleInputWhichContainsAnInsignificantSentence."(les deux chaînes sont citées pour plus de clarté) suffit pour que la plupart des moteurs de regex en marche arrière puissent fonctionner pendant longtemps.

Étant donné que (\s*\w+)*permet l'expansion \w+\w+\w+... \w+, ce qui signifie que le moteur des expressions rationnelles va fondamentalement essayer toutes les manières possibles de scinder une chaîne de caractères . C'est la source de l'enfer de retour en arrière.
Il peut facilement être résolu en changeant \s*à \s+, alors (\s+\w+)*ne peut être étendu à \s+\w+\s+\w+... \s+\w+.

JavaScript

function thiswillLoop(){
var mynumber = 40;
while(mynumber == 40){
mynumber = 050;
}
return "test";
}
thiswillLoop();

050 est une constante octale en Javascript et sa valeur décimale est 40.

Haskell

head $ reverse $ (repeat '!') ++ "olleH"

Eh bien, pense à ça! Ce serait la même chose head $ "Hello" ++ (repeat '!'), c.-à-d. Devrait tout simplement revenir 'H'.

Dans haskell, les listes sont des structures récursives, le premier élément étant le plus important. Pour ajouter une liste à une liste, vous devez dérouler tous ces éléments, placer votre annexe et remettre les éléments soulevés. Cela ne fonctionnerait pas sur une liste infinie. De même, inverser une liste infinie ne vous rendra pas comme par magie "Hello". Il va juste pendre pour toujours.

Java sous Windows

public class DoesntStop
{
    public static void main(String[]a) throws InterruptedException, IOException
    {
        ProcessBuilder p = new ProcessBuilder("cmd.exe","/c","dir");
        p.directory(new File("C:\\windows\\winsxs"));
        Process P = p.start();
        P.waitFor();
    }
}

Le programme s'appuie sur un flux de sortie standard coincé de la ligne de commande pour rester bloqué. Le répertoire WinSXS sous Windows contient plusieurs milliers de fichiers avec des noms longs, de sorte qu'il est presque garanti que le colmatage stdout et waitForque le programme ne peut pas être retourné afin que le programme soit bloqué.

Comparer des pommes et des oranges ... en C

Je suis impressionné par le fait qu'il n'y a pas de code ici qui utilise un goto... (Vous savez: Goto is evil! )

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
    char *oranges = "2";
    long int apples;

next_harvest:

    apples = random() % 3;

    printf("%ld apples comp. %s oranges ...\n", apples, oranges);

    if( apples != (long int)oranges )
    {
        sleep(1);
        goto next_harvest;
    }

    return 0;
}

Le sommeil est juste pour pouvoir le lire. Appuyez sur ^ C si vous ne disposez pas de beaucoup de temps pour attendre quelque chose qui ne se produit jamais ;-)

C, avec certains compilateurs optimiseurs

Ce programme incrémente une variable entière jusqu'à ce qu'elle déborde.

#include <stdio.h>
#include <stdint.h>
int main()
{
    int32_t x = 0;
    while(x + 1 > x)
        x++;
    printf("Got overflow!\n");
    return 0;
}

Le dépassement d'entier signé est un comportement indéfini. Habituellement, dans la pratique, cela se termine lorsque les optimisations sont désactivées. Lorsque les optimisations sont activées, les compilateurs peuvent et doivent décider que cela x + 1 > xest toujours vrai.

C ++

int main()
{
  int x = 1;
  //why doesn't this code terminate??/
  x = 0;
  while(x) {} //no-op/
  return 0;
}

Le style de commentaire étrange est le truc. Indice: trigraphes.

Java

J'aime particulièrement cet effet secondaire de l'optimisation automatique:

class BoxingFun {
  public static void main( String[] args) {
    Integer max;
    Integer i;

    max = 100;
    for( i = 1; i != max; i++ ) {
      System.out.println("Not endless");  
    }
    max = 200;
    for( i = 1; i != max; i++ ) {
      System.out.println("Endless");  
    }
  }
}

En raison de la sélection automatique, les Integerobjets se comportent presque comme des mots simples int, à une exception près: i != maxla forboucle dans la boucle compare les références (identité) des Integerobjets et non leur valeur (égalité). Pour des valeurs allant jusqu'à 100, ceci "fonctionne" de manière surprenante, du fait d'une optimisation dans la machine virtuelle Java: Java préaffecte des Integerobjets pour les "valeurs les plus courantes" et les réutilise lors de la sélection automatique. Donc, pour des valeurs allant jusqu'à 100, nous avons l'identité <==>.

Ruby / C

#include <stdio.h>
#ifdef llama
def int(*args)
end
def main(arg)
  yield
end
void = nil
#endif
#define do {
#define end }
int main(void) {
  int x = 10;
  while(x-=1) do
    printf("%i\n",x);
  end
    return 0;
}

Cela fonctionne correctement en C , le décompte de 9 à 1 dans STDOUT. Lorsqu'il est exécuté en Ruby, il ne se termine pas, car

0 n'est pas une valeur fausse en Ruby.

JavaScript

// This multiplies the elements in the inner lists and sums the results.
function sum_of_products(var items)
{
        var total = 0;
        for(var i = 0; i < items.length; i++) {
                var subitems = items[i];
                var subtotal = 1;
                for(var i = 0; i < subitems.length; i++) {
                        subtotal *= subitems[i];
                }       
                total += subtotal;
        }
        return total;
}

// Should return 1*2 + 3*4*5 + 6*7*8*9 + 10*11 = 3196
sum_of_products([[1, 2], [3, 4, 5], [6, 7, 8, 9], [10, 11]]);

Les deux boucles utilisent la même variable de boucle. Ainsi, en fonction de l'entrée, la boucle interne peut empêcher la boucle externe de se terminer.

C

Cela devrait imprimer une table de codes pour tous les caractères ASCII, de 0 à 255. La valeur de A charest suffisante pour les parcourir.

#include <stdio.h>

int main(){
    char i;
    for(i = 0; i < 256; i++){
        printf("%3d 0x%2x: %c\n", i, i, i);
    }
    return 0;
}

Tous les caractères sont inférieurs à 256. 255 ++ donne 0 en raison d'un débordement. La condition est donc i < 256toujours remplie . Certains compilateurs en avertissent, d'autres non.

Python

a = True
m = 0
while a:
    m = m + 1
    print(m)
    if m == 10:
        exit

cela devrait être exit()et non exit. Si je comprends bien, exit()est la commande pour quitter l’interpréteur python. Dans ce cas, l'appel est à la représentation de la fonction et non à la fonction, voir: discussion de sortie . Sinon, ce breakserait un meilleur choix.

C ++

Qu'en est-il du piège classique du programmeur C ++?

int main()
{
   bool keepGoing = false;

   do {
       std::cout << "Hello, world!\n";
   } while( keepGoing = true );

   return 0;
}

Javascript

var а = 0;
a = 1;
while(а<10){
    a++;
}

Les variables utilisées en 1ère et 3ème ligne sont différentes de celles utilisées en 2ème et 3ème ligne.
L' un utilise un (U + 0061) tandis que l'autre utilise un (U + 0430)

Java:

public class LoopBugThing{
   public static void main(String[] args)
   {
      int i = 0;
      while(i < 10)
      {
         //do stuff here
         i = i++;
      }
      System.out.println("Done!");
   }
}

Le "i = i ++" est une erreur assez courante pour les débutants et peut être étonnamment difficile à trouver

C ++

Un peu de hasard?

class Randomizer
{
   private:
   int max;

   public:
   Randomizer(int m)
   {
      max = m;
      srand(time(NULL));
   }

   int rand()
   {
      return (rand() % max);
   }
};

int main()
{
  Randomizer r(42);
  for (int i = 0; i < 100; i++)
  {
     i += r.rand();
  }
  return (0);
}

N'appelle pas la fonction randmais appelle récursivement la Randomizer::randfonction.

Haskell

Certains codes permettent de chronométrer le calcul d’une valeur donnée de la fonction Ackermann. Pour des valeurs très faibles, il se termine généralement. Sur ma machine, des valeurs très basses signifient quelque chose comme 35 ou moins avec un code compilé et -O. En ghci, les valeurs basses signifient quelque chose comme 3 3.

Le 'symbole semble gâcher la mise en évidence de la syntaxe, sans savoir pourquoi. Dans certains endroits, ils sont nécessaires, ils ne peuvent donc pas tous être supprimés.

Modifier la langue modifiée.

{-# LANGUAGE NamedFieldPuns #-}
import Control.Concurrent.STM
import Control.Concurrent
import Data.Time.Clock.POSIX

data D = D { time :: !POSIXTime
           , m :: !Integer
           , n :: !Integer
           , res :: !(Maybe Integer)
           } deriving Show

startvalue = D 0 3 8 Nothing

-- increment time in D. I belive lensen make code like
-- this prettier, but opted out.
inctime t t' (d@D{time}) = d {time = time + t' - t }

-- Counting time
countTime :: TVar D -> POSIXTime -> IO ()
countTime var t = do
    t' <- getPOSIXTime
    atomically $ modifyTVar' var (inctime t t')
    countTime var t'

-- Ackermann function
ack m n
    | m == 0    = n + 1
    | n == 0    = ack (m - 1) 1
    | otherwise = ack (m - 1) (ack m (n - 1))

-- Ackerman function lifted to the D data type and strict
ack' (d@D{m, n}) = let a = ack m n
                   in seq a (d { res = Just a })

-- fork a counting time thread, run the computation
-- and finally print the result.
main = do
    d <- atomically (newTVar startvalue)
    forkIO (getPOSIXTime >>= countTime d)
    atomically $ modifyTVar' d ack'
    (atomically $ readTVar d) >>= print

Cela provoque un livelock. Le fil de comptage provoque à plusieurs reprises le calcul Ackermann à revenir car ils touchent le même TVar.

Java - Pas de boucles ni de récursivité

Je viens juste de commencer à apprendre les expressions régulières et j'ai écrit mon premier programme pour vérifier si ma chaîne correspond à une expression régulière.

Malheureusement, le programme ne produit aucun résultat. Il supporte le terminal. S'il vous plaît aider à trouver le problème. Je n'ai pas utilisé de boucles, il n'y a pas de récursivité. Je suis complètement dérouté.

import java.util.regex.*;

public class LearnRegex {
     public static void main(String[] args) {
         Pattern p = Pattern.compile("(x.|x.y?)+");
         String s = new String(new char[343]).replace("\0", "x");
         if (p.matcher(s).matches())
             System.out.println("Match successful!");
     }
}

Qu'est ce que j'ai mal fait? Pourquoi mon programme ne se termine-t-il pas? S'il vous plaît aider!

Lien Ideone ici .

C'est un exemple stupide de retour en arrière catastrophique . La complexité est O (2 ^{n / 2} ). Alors que le programme pourrait ne pas fonctionner indéfiniment, ce serait probablement survivre à la fois vivant et non vivant des objets autour et pas si autour .

C

Vous ne devriez avoir besoin que d’une des deux boucles, mais celle dont vous avez besoin dépend de votre compilateur.

main()
{
        int i, a[10];

        i = 0;
        while (i <= 10) {
            i++;
            a[i] = 10 - i;
            printf("i = %d\n", i);
        }

        /* Now do it in reverse */

        i = 10;
        while (i >= 0) {
            i--;
            a[i] = 10 - i;
            printf("i = %d\n", i);
        }

}

Un simple dépassement des limites qui réinitialise i sur une valeur non terminale. Les compilateurs peuvent différer selon qu'ils allouent i au-dessus ou au-dessous de a sur la pile. J'ai donc inclus les dépassements dans les deux sens.

C / C ++

C ++ n'autorise que les déclarations de variables en ligne simples utilisées ici, mais il est tout aussi facile de faire cette erreur en clair vieux C ...

#include <stdio.h>

int main(void)
{
    int numbers[] = {2, 4, 8};

    /* Cube each item in the numbers array */
    for(int i = 0; i < 3; i++) {
      for(int j = 0; j < 3; i++) {
        numbers[j] *= numbers[j];
      }
    }

    /* Print them out */
    for(int i = 0; i < 3; i++) {
      printf("%d\n", numbers[i]);
    }

    return 0;
}

Dans la boucle interne, "j" est comparé mais jamais incrémenté. (Le 'i ++' devrait être réellement 'j ++'). Ce n'est pas vraiment un tour sournois, mais plutôt une erreur réelle que j'ai commise dans le passé;) Quelque chose à surveiller.

C #

Ce qui suit est une classe simple effectuant une opération arithmétique (somme) sur un grand tableau en entrée utilisant un thread en arrière-plan. Un exemple de programme est inclus.

Cependant, même si c'est assez simple, cela ne se termine jamais. Notez qu'il n'y a pas de tour de passe-passe (sosies de caractères, points-virgules cachés / manquants, trigraphes ;-), etc.)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading;

class Program
{
    static void Main()
    {
        var summer = new BackgroundSummer(Enumerable.Range(1, 1234567));
        Console.WriteLine(summer.WaitAndGetResult());
    }
}

public class BackgroundSummer
{
    private IEnumerable<int> numbers;
    private long sum;
    private bool finished;

    public BackgroundSummer(IEnumerable<int> numbers)
    {
        this.numbers = numbers;
        new Thread(ComputingThread).Start();
    }

    public long WaitAndGetResult()
    {
        while (!finished) { /* wait until result available */ }
        return sum;
    }

    private void ComputingThread()
    {
        foreach(var num in numbers)
        {
            sum += num;
        }
        finished = true;
    }
}

Ceci est un exemple de bogue méchant du monde réel pouvant également apparaître dans votre code. Selon le modèle de mémoire .NET et la spécification C #, une boucle telle que celle dans WaitAndGetResultpeut ne jamais se terminer si vous ne spécifiez pas la variable comme volatile, car elle est modifiée par un autre thread. Voir cette question StackOverflow pour plus de détails. Le bogue dépend de l'implémentation .NET, il peut donc vous affecter ou non. Mais généralement, l'exécution d'une version compilée sur un processeur x64 semble afficher le problème. (Je l'ai essayé avec “csc.exe / o + / debug- infinite.cs” .)