1

Non, TIGCC n'est pas mort, son développement n'est pas arrêté. Je viens d'importer une implémentation de stdint.h, complète avec documentation, contribuée par Conrad Meyer. Ce sera inclus dans la prochaine version de TIGCC.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

2

ok, joyeux noel à toi aussi.
Tout ce qui passe pas par le port 80, c'est de la triche.

3

Pourquoi avoir défini les types int_fast8_t et uint_fast8_t identiques à int16_t et uint16_t ? De mémoire, les accès 8 bits et 16 bits sont aussi rapides les uns que les autres, donc on aurait pu définir int_fast8_t et uint_fast8_t identiques à int8_t et uint8_t.

Ce sera aussi inclus dans la prochaine version de TIGCC-fork (appelons-le comme ça pour le moment), parce que ça y était déjà grin
TIGCC-fork a déjà un stdint.h complet ( http://www.mirari.fr/5cpr ) et un inttypes.h partiel (puisque les types 64 bits ne sont pas gérés par le printf de la plate-forme). Ces deux headers sont intégrés dans le système de documentation de TIGCC (.hsf & .hsh, voir par exemple http://www.mirari.fr/OGX4 ) et les .hsf sont eux-mêmes auto-générés par des scripts Perl (environ 200 SLOC au total).
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

4

Et ben, merci pour avoir fait le tout en privé sans le contribuer. roll Et la documentation de Conrad est meilleure. tongue
[Explanation] Definition mandated by the C99 standard.

... roll

Et les divisions de char sont plus lentes car obligé de faire une extension de signe/zéro.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

5

Et ben, merci pour avoir fait le tout en privé sans le contribuer. roll

Tu es très mal placé pour nous faire le reproche: c'est toi le responsable de cet état de fait.
En effet, le travail dans TIGCC-fork de stdint.h et inttypes.h comme tu les veux (intégrés au système de documentation) est partiellement postérieur à la contribution des deux patches postés à http://tichessteamhq.yuku.com/topic/4650 , qui n'ont toujours pas été mergés. Bien que nous ayions pris le temps de refaire ces patches dernièrement (alors qu'on aurait très bien pu te laisser faire le s///g) pour qu'ils soient plus conformes à tes désirs.

Pourquoi est-ce qu'on s'amuserait à contribuer des modifs supplémentaires (un troisième patch) alors que tu n'as toujours pas mergé les deux premiers patches ? D'autant plus que tu m'écris en privé des choses déplaisantes témoignant d'un énorme irrespect, notamment envers moi (il n'y a pas que ce que j'ai quoté dans ma signature), ce qui n'incite pas à vouloir travailler avec un personnage comme toi...

As-tu rendu public le patch de Conrad Meyer avant de le committer dans le repository CVS TIGCC ? Si ce n'est pas le cas, tu n'as pas fait preuve de transparence, à laquelle tu écris pourtant croire, dans le topic sus-mentionné.
Et les divisions de char sont plus lentes car obligé de faire une extension de signe/zéro.

Justification valide à laquelle on n'avait pas pensé. On va changer les définitions du fork smile
[EDIT: c'est fait.]
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

6

(juste en passant : si vous voulez pas qu'il vienne vous pourrir les topics "tigcc-fork", une idée serait peut-être de ne pas venir lui pourrir les topics "tigcc-non-fork" ? )
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

7

pencil on a déjà vti/tiemu, gnu as/a68k, pas la peine de se bagarrer encore entre deux softs dont la philosophiede développement n'a rien à voir.

8

Soit. J'aurais dû ne poster que le premier paragraphe de ./3.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

9

Lionel Debroux (./5) :
As-tu rendu public le patch de Conrad Meyer avant de le committer dans le repository CVS TIGCC ? Si ce n'est pas le cas, tu n'as pas fait preuve de transparence, à laquelle tu écris pourtant croire, dans le topic sus-mentionné.

Ce patch a moins d'une semaine, il a été commité aussi rapidement que possible, l'uploader plus rapidement n'aurait pas servi à grand chose. Et il a été discuté sur #tigcc. smile
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

10

OK, c'était donc public. Bien smile

C'était donc à ce patch que tu faisais référence par
tu as réinitialisé le temps de traîtement de tes patches, ils ont été mis au fond de mes priorités et il y a au moins une autre contribution qui passera devant.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

11

Oui.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

12

Pour en revenir au sujet: je pense qu'il est possible d'améliorer ce que Conrad a fait et que Kevin a committé. Ca aurait été possible de se rendre compte auparavant de la duplication d'efforts à plusieurs reprises, entre autres exemples la fréquentation de #tigcc par les bonnes personnes au bon moment ou l'utilisation (enfin !) par le projet TIGCC d'un bug + feature request + patch tracker ou de tout autre outil plus permanent et mieux adapté à la tâche qu'un channel IRC.

Il y a des trucs bien dans la formulation de Conrad:
[ul][li]"In TIGCC, this type is exactly <n> bits."[/li]
[li]une distinction plus explicite entre size et speed.[/li][/ul]

En revanche:
[ul][li]le "our" des formulations "Maximum/minimum value of our <...> type." me paraît très bizarre: pourquoi pas "the" à la place de "our" ?? C'est le standard C99 qui définit le type, pas "nous" projet TIGCC.[/li]
[li]La doc de Conrad mentionne C99 de façon inconsistante (certains .hsf l'ont en Description, pas d'autres). Dans TIGCC-fork, la spécification C99 est mentionnée dans le .hsh et dans la section Explanation des .hsf, mais jamais dans la section Description des .hsf. [/li]
[li]question de goût: la formulation de stdint.h (et inttypes.h, d'ailleurs) de TIGCC-fork est proche de la formulation qu'on peut trouver dans C99+TC1+TC2. Ce sont donc des définitions plus précises et moins accessibles que celles de Conrad.[/li][/ul]

Voir http://lionel.debroux.free.fr/pub/.stdint.html .
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

13

Lionel Debroux (./12) :
le "our" des formulations "Maximum/minimum value of our <...> type." me paraît très bizarre: pourquoi pas "the" à la place de "our" ?? C'est le standard C99 qui définit le type, pas "nous" projet TIGCC.

"Notre" type uint_least16_t par opposition à celui de GNU/Linux par exemple.
C99 spécifie qu'il doit y avoir un tel type, mais le type concret est à nous.
La doc de Conrad mentionne C99 de façon inconsistante (certains .hsf l'ont en Description, pas d'autres). Dans TIGCC-fork, la spécification C99 est mentionnée dans le .hsh et dans la section Explanation des .hsf, mais jamais dans la section Description des .hsf.

Ça ne me dérange pas vraiment, mais ça peut se changer. (Mais il me faudra des propositions de quoi changer exactement.)
question de goût: la formulation de stdint.h (et inttypes.h, d'ailleurs) de TIGCC-fork est proche de la formulation qu'on peut trouver dans C99+TC1+TC2. Ce sont donc des définitions plus précises et moins accessibles que celles de Conrad.

Et les droits d'auteur dans tout ça? (Le standard n'est pas libre de droits ni libre au sens du logiciel libre, on ne peut pas le copier mot pour mot.)
De plus, le "standardese" n'a jamais été ce qu'il y a de plus lisible.

Qu'est-ce qui n'est pas clair dans les descriptions de Conrad à ton avis?
Voir http://lionel.debroux.free.fr/pub/.stdint.html .

Je vais dire ce qui ne me va pas dans cette documentation:
* Description est trop longue. Ça doit être une description courte, donc des formulations comme "Integer constant expression having the value specified by its argument and ..." sont trop longues pour Description. À la limite pour Explanation, mais c'est quand-même du "standardese", cf. plus haut.
* Explanation est trop courte, souvent plus courte que Description, il manque des détails que la version de Conrad apporte.
* Explanation est du copier-coller scripté "Definition mandated by the C99 standard." qui n'apporte aucune information (tout le header est spécifié par C99).
* Dans la documentation de (par exemple) INT16_C, il y a "Integer constant expression having the value specified by its argument and the type int_least16_t.", mais il n'y a pas de lien pour int_least16_t. (C'était comme ça aussi dans la première version de Conrad, je lui ai demandé de corriger ça et il l'a fait rapidement avec un petit script.)

Quant à inttypes.h, je ne vois pas l'intérêt de proposer ce header non-standard.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

14

le "our" des formulations "Maximum/minimum value of our <...> type." me paraît très bizarre: pourquoi pas "the" à la place de "our" ?? C'est le standard C99 qui définit le type, pas "nous" projet TIGCC.

"Notre" type uint_least16_t par opposition à celui de GNU/Linux par exemple. C99 spécifie qu'il doit y avoir un tel type, mais le type concret est à nous.

Ah, OK.
Peut-être que quelque chose du genre "Maximum/minimum value of the <...> type for 68000 processor" serait plus clair ?

* Dans la documentation de (par exemple) INT16_C, il y a "Integer constant expression having the value specified by its argument and the type int_least16_t.", mais il n'y a pas de lien pour int_least16_t. (C'était comme ça aussi dans la première version de Conrad, je lui ai demandé de corriger ça et il l'a fait rapidement avec un petit script.)

Ca serait facile à corriger pour nous aussi, en effet.
Quant à inttypes.h, je ne vois pas l'intérêt de proposer ce header non-standard.

Ben... si, il est standard grin

Même au cas où tu n'aurais pas le PDF C99 ou C99+TC1+TC2, tu peux le voir dans /usr/include/inttypes.h:
[code]/*
* ISO C99: 7.8 Format conversion of integer types <inttypes.h>
*/[/code]


La feature request "stdint.h" aurait pu être postée dans le bug + feature request + patch tracker de TIGCC s'il y en avait un wink
On ne peut pas te reprocher de ne pas y avoir pensé, mais tu savais que stdint.h avait été à l'origine fait par un des créateurs de TIGCC-fork, qui te l'avait contribué (pas au format du système de documentation TIGCC) - il était donc possible qu'il fasse partie de la wish list du fork.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

15

Lionel Debroux (./14) :
Peut-être que quelque chose du genre "Maximum/minimum value of the <...> type for 68000 processor" serait plus clair ?

Non, parce que différentes plateformes basées sur le Motorola 68000 peuvent faire différents choix.

OK pour inttypes.h, j'aurais dû vérifier dans ma copie de N1124 effectivement. Avez vous une implémentation complète (ou du moins non-triviale - il faudrait pas mal de trucs pour une implémentation vraiment complète, TIGCC n'a même pas de wchar_t à l'heure actuelle) de inttypes.h dans votre SCM ou seulement #include <stdint.h>? Si vous avez une implémentation non-triviale, puis-je la voir?

Et quid de mes autres remarques et surtout mes questions? (En particulier "Qu'est-ce qui n'est pas clair dans les descriptions de Conrad à ton avis?")
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

16

Peut-être que quelque chose du genre "Maximum/minimum value of the <...> type for 68000 processor" serait plus clair ?
Non, parce que différentes plateformes basées sur le Motorola 68000 peuvent faire différents choix.

Sur d'autres membres de la famille 68k, oui. Mais existe-t-il une implémentation du 68000 (encore une fois, le vrai 68000, pas un autre membre de la famille 68k) ou des choix de "least" et "fast" seraient différents ?
"Maximum/minimum value of the <...> type for the TI-68k processor" ou "Maximum/minimum value of the <...> type for the 68000 processor of/in TI-68k calculators" ?
(Ca va finir par devenir long).

Actuellement, dans TIGCC-fork, inttypes.h ne définit que les macros PRI* et SCN*. J'ai déjà utilisé les macros PRI* dans un projet réel qui utilise lourdement les types de stdint.h.
En revanche, vu que ni le printf ni le strtoul de l'OS habituel des TI-68k ne supportent les long long (et que le scanf que tu as implémenté ne le supporte pas, du moins la doc ne l'indique pas), nous ne nous sommes pas amusés à définir|implémenter imaxdiv_t, imaxabs (celui-là existe certainement dans la libgcc, c'est la routine qui donne la valeur absolue d'un long long), imaxdiv, strtoimax/strtoumax et encore moins wcstoimax/wcstoumax.
Je ne pense pas que cela ait une vraie utilité pratique d'implémenter le support wide char dans TIGCC: l'OS fabricant ne sait pas ce que c'est. Bien sûr, des OS alternatifs peuvent avoir envie de l'implémenter, mais à ce moment-là, je pense que c'est à eux de complémenter les headers et la lib.

http://lionel.debroux.free.fr/pub/.inttypes.html . Pareil que stdint.h: auto-généré à partir d'un header sans documentation, formulation "standardese", "Definition mandated by the C99 standard", *actuellement* pas de liens vers les types.

Et quid de mes autres remarques et surtout mes questions?

Principalement accord tacite.
* Description est trop longue. Ça doit être une description courte, donc des formulations comme "Integer constant expression having the value specified by its argument and ..." sont trop longues pour Description. À la limite pour Explanation, mais c'est quand-même du "standardese", cf. plus haut.

Je connais le défaut de lisibilité du "standardese", je l'ai écrit dans ./12 wink
* Explanation est trop courte, souvent plus courte que Description, il manque des détails que la version de Conrad apporte.

OK. Un détail supplémentaire apporté par la version de Conrad est signalé en ./12 wink
* Explanation est du copier-coller scripté "Definition mandated by the C99 standard." qui n'apporte aucune information (tout le header est spécifié par C99).

Je suis d'accord.
Qu'est-ce qui n'est pas clair dans les descriptions de Conrad à ton avis?

Les définitions de Conrad sont claires (sauf, à mon avis, le "our", on en cause par ailleurs), mais moins précises que le standard C99. "Question de goût" dans ./12 indique que c'est débattable.
Puisqu'il s'agit d'un standard international ISO, je ne m'étais même pas posé la question du droit d'auteur. Les standards sont faits pour qu'on puisse s'appuyer dessus.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

17

S'il y en a qui se demandent pourquoi TIGCC et TIGCC-fork coopèrent sur inttypes.h, c'est très simple: contrairement au support de VTI dans l'IDE Delphi (pour ne citer que cet élement des todo/wish lists), stdint.h/inttypes.h ne sont pas sujets à polémique.
On sait que ces headers se retrouveront tôt ou tard des deux côtés, on n'est pas obligés d'être idiots.

Pour stdint.h, aucun des deux côtés ne savait que l'autre avait l'intention de le faire / l'avait déjà fait.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

18

Lionel Debroux (./16) :
imaxabs (celui-là existe certainement dans la libgcc, c'est la routine qui donne la valeur absolue d'un long long)

Le abs de TIGCC fonctionne sur n'importe quel type numérique (entier ou flottant). C'est très simple à définir comme macro.
Lionel Debroux (./17) :
Pour stdint.h, aucun des deux côtés ne savait que l'autre avait l'intention de le faire / l'avait déjà fait.

Non seulement je ne savais pas que tu avais déjà un stdint.h dans le bon format (même si la documentation est incomplète), mais je ne pouvais pas non plus t'informer sur nos plans parce qu'ils n'existaient pas, Conrad a décidé d'écrire un stdint.h le 20 décembre. Ça a été fait beaucoup plus rapidement que je le prévoyais, d'ailleurs. Je ne l'avais pas fait moi-même parce que je comptais une quantité de travail immense. Visiblement je fais trop de choses à la main et je ne me sers pas assez de scripts. (L'inverse peut être mauvais aussi, mais il est clair que les ordinateurs sont là pour faire les tâches répétitives pour nous.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

19

imaxabs (celui-là existe certainement dans la libgcc, c'est la routine qui donne la valeur absolue d'un long long)
Le abs de TIGCC fonctionne sur n'importe quel type numérique (entier ou flottant). C'est très simple à définir comme macro.

Bien sûr. Là, je parlais de l'existence de la routine qui implémente la fonctionnalité, pas de la définition de imaxabs dans le header.
Mais comme printf & scanf ne connaissent pas les types 64 bits, on a remis à plus tard (éventuellement jamais) un support des (u?)intmax_t.



J'ai bien compris que ce n'était pas prévu d'écrire un stdint.h. MAIS tu écris toi-même que cette idée, ce souhait flottait déjà quelque part chez toi:
Je ne l'avais pas fait moi-même parce que je comptais une quantité de travail immense.

Je ne sais pas s'il était uniquement dans ta tête ou si tu l'avais écrit dans un fichier sur tes machines, mais (à ma connaissance) ce souhait n'était pas diffusé sur un outil adapté à la gestion de todo/wish lists (Bugzilla, Forge, Trac, etc.).


Ca n'a en effet pas pris beaucoup de temps, à Conrad comme à moi, de faire un générateur de .hsf pour stdint.h et inttypes.h (qui sont des headers un peu particuliers par leur redondance). J'ai donné le chiffre d'environ 200 SLOC (Perl, ça serait similaire avec Python ou Ruby) pour stdint.h + inttypes.h.
C'est clair qu'il ne faut pas tout faire en langages de script (diverses distros GNU/Linux modernes, avec par exemple de lents gestionnaires de package et de dépendances écrits en Python, ont malheureusement oublié cela...), mais il est très dommage de ne pas utiliser le sucre syntaxique et les builtins de manipulation de données fournis par PPPR pour faire des programmes de manipulation de données qui vont jusqu'à quelques milliers de lignes.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

20

Lionel Debroux (./19) :
Bien sûr. Là, je parlais de l'existence de la routine qui implémente la fonctionnalité, pas de la définition de imaxabs dans le header.

Bah, une macro d'une ligne suffit. Ce n'est pas vraiment conforme au standard d'avoir ça seulement sous forme de macro, mais c'est le cas aussi de nombreuses autres fonctions de TIGCCLIB.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

21

Tiens, je viens de voir une autre différence entre les stdint.h de TIGCC et GCC4TI: dans GCC4TI, nous avons fait le choix de suivre C99+TC1+TC2 (paragraphe 7.18.2) pour les valeurs de INT*_MIN, INT_FAST*_MIN, INT_LEAST*_MIN et INTMAX_MIN. A savoir, que la valeur -2^(N-1) n'est pas autorisée, aussi bizarre que ça paraisse.
Même remarque pour INTPTR_MIN, si ce n'est que TIGCC et GCC4TI ont tous les deux étendu la plage à 32 bits (une plage de 16 bits, quand les pointeurs font plus de 16 bits, paraît bizarre).

Qu'est-ce qu'on fait ?
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

22

Ton interprétation de C99 est fausse.
Clause 7.18.2, paragraphe 2:
Its implementation-defined value shall be equal to or greater in magnitude (absolute value) than the corresponding value given below, with the same sign, except where stated to be exactly the given value.

Or "exactly" est écrit seulement pour les INTN_MIN, et dans ce cas la valeur est spécifiée à "exactly -(2N-1)". Pour les autres INT*_MIN, les valeurs sont spécifiées comme étant <= -(2N-1-1) (>= en valeur absolue), donc une valeur de -(2N-1) est conforme. De plus, cette valeur est logique, correcte (c'est le vrai minimum du type), cohérente avec les autres *_MIN et compatible avec d'autres systèmes (regarde par exemple le stdint.h de GNU/Linux). Donc votre implémentation est fausse, celle de Conrad est correcte.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

23

ACK.
>= fait que notre implémentation n'est pas fausse. Elle est juste moins logique que celle de Conrad.
J'avais regardé /usr/include/stdint.h.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

24

7.18.4.1 indique
The macro INTN_C(value) shall expand to an integer constant expression corresponding to the type int_leastN_t. The macro UINTN_C(value) shall expand to an integer constant expression corresponding to the type uint_leastN_t.


Sachant que (7.18.1.2)
The typedef name int_leastN_t designates a signed integer type with a width of at least N , such that no signed integer type with lesser size has at least the specified width. Thus, int_least32_t denotes a signed integer type with a width of at least 32 bits.
The typedef name uint_leastN_t designates an unsigned integer type with a width of at least N , such that no unsigned integer type with lesser size has at least the specified width. Thus, uint_least16_t denotes an unsigned integer type with a width of at least 16 bits.


la formulation (dans INT8_C):

[Description]
Appends the correct suffix to an 8-bit signed integer literal.

[Explanation] This macro appends the correct suffix for an 8-bit signed integer literal to <I>c</I>.

n'est pas précise, puisqu'un (u?)int_leastN_t pourrait faire plus de N bits. Il manque une mention de "on the TIGCC platform".
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.