Peut-être certaines fonctions système qui n'ont pas tout à fait le même comportement ? Je pense à system("pause") par exemple

Que veux tu dire par « fonctions systèmes » :
- int system (const char *command ) sur différents OS ?
- Les appels systèmes ?
- Les commande CLI ?

Pas besoin de windows.h pour faire un code-non portable...
Par exemple, sous windows, system("cls"); efface ce qui est affiché dans la console.
Sous les systèmes de base unix, c'est system("clear");

C'est peut-être de la mauvaise foi, mais là, c'est TOI le PEBKAC

Pourquoi aller chercher si loin ?
Une différence de taille sur les types simples est suffisante pour introduire une différence de comportement à l'exécution.
Un long int sous Windows et un long int sous Mandriva n'ont pas forcément la même taille.

En attendant, ce qui me surprend, c'est que le même langage, avec le même compilateur, attende des instructions différentes pour exécuter la même action, alors que justement, ce qu'on demande à un compilateur, c'est de ne pas être embêté avec le soft ni le hard sous-jacent.

Il y a très probablement une raison là dessous (vu qu'on a créé, justement, des langages exprès pour ne plus que ça arrive), mais que j'ignore.

Non, l'indépendance du matériel, c'est le travail de l'OS. Alors forcément, quand on change d'OS...

Cela ne répond pas à mon interrogation... quant au votre moins, il fait penser qu'on a pas le droit de poser des questions ici. Décevant.

@Aaargh!!! /a:::::::rg/ :

Je t'ai plussoyé pour rétablir l'équilibre. Et je suis d'accord, ce n'est pas la première fois que je vois quelqu'un monsoyé pour l'unique raison qu'il s'étonne de quelque chose ou dit en ignorer la raison.

Merci Skefrep pour ton soutien ;-)

PS : en voulant te plussoyer, j'ai placé le curseur sur MON plus à moi, et évidemment, je m'étonnais que ça ne fonctionne pas ! CMLP !

@Aaargh : Tant qu'on ne sait pas qui a moinssoyé, tu sais... Tous les avis n'ont pas la même importance. Surtout que tous les trois PEBKACs, on a un avis d'erreur de vote pour cause de gros doigts.

@Aaargh : En fait, le C est suffisamment bas niveau pour pouvoir passer des instructions directement à la ligne de commande ( ce qu'a l'air de faire le system() ). Et comme ce que tu passes en argument à cette fonction n'est rien de plus qu'une chaine de caractères, le compilateur ne peut pas deviner ce qu'il y a à l'intérieur (ou du moins n'est pas configuré pour : Le compilateur C chercher les erreurs de syntaxe, pas les erreurs de runtime). Du coup, effectivement, je dirais je le même code source en C peut se comporter différamment sur différents OS.

PS: Cela demande confirmation, je suis loin d'être un crack de C !

Ok, là je comprends mieux ! Merci pour ton explication.

Et c'est pareil dans d'autres langages, tant qu'une fonction existe pour envoyer des commandes à l'OS, et bien ça merde si ce dernier change.

Pas la peine de faire appelle aux commandes de l'OS, écrire du code portable est largement plus subtile que ça, notamment en C :
- Les types n'ont pas forcément la même taille (ex1: transtyper un size_t dans un long ne pose pas de problème sous Win32 ou Unix sur PC, mais est à ne surtout pas faire sous z/OS. Ex2: Sous Z/OS un long fait 32 ou 64 bits suivant les options de compilation).
- Les "constantes" genre EOF n'ont pas forcément le même valeur d'une machine à l'autre (sous Windows: 0, sous z/OS: -1, si on a un transtypage implicite dans un test ça passe sous Win, ça bug sous z/OS).
- L'ordre des octets en mémoire n'est pas forcément le même.
- L'organisation mémoire n'est pas forcément la même, ce qui peut entrainer un comportement différent suite à un écrasement mémoire (qui peut passer inaperçu ou non) ou une lecture de fichier écrit avec une autre version (l'organisation mémoire des structures dépend de options de compil).
- Les fonctions système n'ont pas forcément le même comportement.
- Le compilateur ne respecte pas forcément les normes.
- Le jeu de caractère n'est pas forcément le même (ex: en EBCDIC les lettres ne sont pas contiguës et '0' > 'A',
contrairement à l'ANSI).
- Le passage des arguments effectifs aux fonctions/sous-programmes ne se fait pas forcément de la même manière.
- L'adressage mémoire peut être interprété différemment (sous z/OS en AMODE31 le 32ème bit des pointeurs n'est pas pris en compte, mais s'il est positionné en AMODE64 on a une erreur d'exécution).

Ça, c'est pour les subtilités qui passent à la compil mais pas à l'exécution.
On peut aussi avoir un jeu d'instruction différent (ex: l'instruction Compare&Swap n'existe que sur les proc des mainfraimes IBM).

A l'école d'ingé on devait utiliser les signaux pour un projet en C, et le même code compilait partout mais ne fonctionnait pas sur toutes les machines pourtant toutes des Linux, donc rien que passer d'une distribution à une autre peut donner des erreurs d'exécution.

Donc non pas forcément de mauvaise fois...

Ça ne serait pas une histoire de commande externe propre au système en question ?

cls est une commande MS-DOS, clear une commande bash et shell. Donc forcément, l'un marche sur un système, l'autre non, et inversement.

Je suppose que si l'ont fait un alias nommé cls pour lancer clear, soudainement, system("cls") marche aussi sur les systèmes GNU/Linux, BSD et consort.

A ma connaissance, personne d'autre n'avait ce genre de problème, et ce qu'il fallait faire ne nécessitait pas d'appel à des commandes système.

C'est pour ça qu'on avait tendance à penser qu'il en rajoutait un peu (étant donné qu'il n'a jamais caché qu'il n'aimait pas Linux).

Mais ensuite c'est vrai que je ne suis jamais allé voir ce qui buggait dans son code, d'autant plus que c'était pour un exam.

Mea culpa.

Mauvaise fois je ne sais pas, les os peuvent être très susceptibles et caractériels.