livre sur C, que choisir?

Moi je vois pas mal d'erreur dans ce code, pour commencer: pas de fonction main(), ensuite printf() est non défini: stdio.h ensuite les
#include <stddef.h>
#include <assert.h>

me paraissent ici inutile, et enfin un dernier truc, pourquoi passer N en #define et pourquoi pas en tant que variable toute bete ?
enfin moi je dis ça juste pour que tu en apprennes un peu plus sur le C...

Si c'est à moi que s'adresse le commentaire il n'a rien de fondé . Le petit "test" de InOcamlWetrust ne portait absolument sur le fait que je vois ou pas la presence de <stdio.h> et merci je l'avais vu.
Quand aux autre include il avait mis /* du code */ pour montre qu'il peut y avoir du code avant .
l'absence de main c'est pareille tout le monde sais qu'il faut un point d'entrée et la merci on a pas besoin de sortir de l'X pour le savoir ou le voir.
Le but de l'exercice était uniquement de savoir si je me ferais piégé par le type no signé et le N en define n'était qu'une leurre donc pour moi l'exmple qu'il a donné est correct si l'on comprend sur quoi il voulait mettre l'accent...

Oui, c'est exactement ça : je pense que sur un forum, il vaut mieux se concentrer sur la partie critique du code, et ne pas s'attarder sur des choses qui n'apportent pas grand chose au débat, étant donné qu'un grand nombre de personnes sont censées lire le code en question.

Pour le coup du #include <assert.h> c'est une erreur : j'avais pensé mettre un assert(0) dans la boucle, au début, mais j'ai changé d'idée en pondant le code.

Pour ce qui est des subtilités du langage C, je vais te donner un exemple, le mien.

Je suis actuellement en deuxième année d'école d'ingénieurs, à l'ENSEEIHT ; l'année dernière, vers le mois de Décembre, plus ou moins, on a eu droit à 6 ou 7 heures de cours sur le C et une quinzaine de TP's qui se sont poursuivis jusqu'en Mars. Les cours sont assez corrects, dans l'ensemble (bien que les profs ne soient pas toujours au fait at pas toujours d'accord entre eux...).

A la fin de la période de formation à proprement parler sur le C, je savais pas mal de choses (enfin, les bases, quoi, un peu plus que toi actuellement, je pense), mais je sentais que je n'en savais pas assez, surtout au niveau de la déclaration des types et de leur utilisation (et autres), car j'appliquais bêtement, faute d'autres sources d'informations, les mêmes schémas vus en cours et TP.

Sur un conseil de mon prof de TP, je me suis acheté le K&R (deuxième édition), afin d'en savoir plus sur la norme ANSI, qui fait référence en la matière. Je me suis alors mis à étudier à fond le C en dehors des nombreuses heures de cours (32 heures par semaines) et des longs projets à la pelle (à faire en dehors des heures de cours). Il ne m'aura finalement fallu qu'à peine 6mois pour avoir une bonne vision, précise et concise dans l'esprit du langage C (car le C est petit, peu compliqué mais possédant tout de même quelques règles particulières). Je ne me forçais pas, et je ne le faisais pas à la manière d'un mec qui reste enchaîné toute la journée devant son PC... je le faisais simplement par goût et par soucis de précision vis-àvis de ce langage qui au départ me rebutait énormément et que finalement j'adore.

Je pense sincèrement qu'avec un investissement constant tu peux arriver en l'espace de peu de temps à maîtriser le langage. Et comme je l'ai dit, le C ne possède pas beaucoup de règles, mais seulement quelques unes qui sont, cependant, très précises dans la formulation et qu'il est vivement recommandé de connaître, à l'image de celles gouvernant les types incomplets (que l'on retrouve très souvent si on veut faire des arbres ou des listes !).