Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

invalid octal number

24 views
Skip to first unread message

Kroc

unread,
Jul 20, 2006, 11:06:47 AM7/20/06
to
On l'a tous eu au moins une fois ce message, et si c'est pas le cas
voilà comment ça arrive :

% set a 08
% incr a
expected integer but got "08" (looks like invalid octal number)

Alors qu'on attend 09 ou à la limite 9 :-/

La parade consiste à transformer 08 en 8 ou 08.0 avant d'effectuer la
moindre opération dessus :

set a [expr int($a.0)] ; # et surtout pas : set a [expr {int($a.0)}]

C'est pas propre mais au moins ça marche. Mais comme c'est pas propre
ça ne me plaît pas, alors j'aimerai bien savoir comment on peut
faire ça proprement ?

Et tant que j'y suis, j'aimerai aussi savoir à qui / quoi ça peut
bien servir que Tcl considère par défaut ces nombres comme des
octaux...

--
David Zolli - Kroc

Kroc

unread,
Jul 20, 2006, 11:15:38 AM7/20/06
to

> .../...

> C'est pas propre mais au moins ça marche. Mais comme c'est pas propre
> ça ne me plaît pas, alors j'aimerai bien savoir comment on peut
> faire ça proprement ?

J'ai trouvé un truc propre :

set a [expr {int([format %f $a])}]

> Et tant que j'y suis, j'aimerai aussi savoir à qui / quoi ça peut
> bien servir que Tcl considère par défaut ces nombres comme des
> octaux...

Je sais toujours pas..

david cobac

unread,
Jul 20, 2006, 11:18:50 AM7/20/06
to
"Kroc" <kr...@kroc.tk> a écrit :
>[...]

>set a [expr int($a.0)] ; # et surtout pas : set a [expr {int($a.0)}]
>
>C'est pas propre mais au moins ça marche. Mais comme c'est pas propre
>ça ne me plaît pas, alors j'aimerai bien savoir comment on peut
>faire ça proprement ?

une autre solution :
set a [string trimleft $a 0]
est-elle propre au sens krocien ?

>
>Et tant que j'y suis, j'aimerai aussi savoir à qui / quoi ça peut
>bien servir que Tcl considère par défaut ces nombres comme des
>octaux...

Disons que l'écriture entière avec un 0 devant est celle qui a été
adoptée pour les octaux. Je pense que c'est tout à fait criticable (pour
un novice comme moi).
Je me suis jamais servi des octaux, je suis effectivement comme bon nombre
de personnes tombé sur cette erruer en manipulant l'heure.

--
cordialement
david cobac

J'ai été très surpris de constater que TCL a beaucoup été évoqué dans
les médias en ce début de semaine.
Malheureusement, il s'agissait d'un constructeur de téléviseurs :-(
Bon, cela fait quand même plaisir d'entendre le mot TCL à la radio ou à
la TV :-)
-+- gerard in fr.comp.lang.tcl -+-

Kroc

unread,
Jul 20, 2006, 11:36:32 AM7/20/06
to
david cobac a écrit :

> une autre solution :
> set a [string trimleft $a 0]
> est-elle propre au sens krocien ?

Tout à fait puisque c'est une utilisation conforme de la commande.

> >Et tant que j'y suis, j'aimerai aussi savoir à qui / quoi ça peut
> >bien servir que Tcl considère par défaut ces nombres comme des
> >octaux...
>
> Disons que l'écriture entière avec un 0 devant est celle qui a été
> adoptée pour les octaux. Je pense que c'est tout à fait criticable (pour
> un novice comme moi).
> Je me suis jamais servi des octaux, je suis effectivement comme bon nombre

> de personnes tombé sur cette erreur en manipulant l'heure.

Ah, je suis pas le seul alors !

En tout cas, criticable ou pas je pense qu'on va devoir en faire notre
deuil. Le TCT ne va probablement jamais corriger ça, ne serait-ce que
pour conserver la compatibilité des anciens scripts.

Dommage, parce que c'est vraiment idiot !

ulis

unread,
Jul 20, 2006, 11:57:15 AM7/20/06
to
Tcl and octal numbers
http://wiki.tcl.tk/TclAndOctalNumbers

TIP #114: A System for Non-Decimal Numeric Values
http://www.tcl.tk/cgi-bin/tct/tip/114.html

Hop! que ça helpe

ulis

david cobac

unread,
Jul 20, 2006, 12:13:17 PM7/20/06
to
"ulis" <mauric...@gmail.com> a écrit :
>[...]

>TIP #114: A System for Non-Decimal Numeric Values
> http://www.tcl.tk/cgi-bin/tct/tip/114.html
>[...]
On y lit :
"The only common use of octal values in both the core and a number of
important extensions seems to be in the manipulation of UNIX permission
strings. "

ah ben oui...maintenant c'est pas un usage très fréquent (je parle pour
moi), c'est la commande file attributes qui a une option -permissions
qui accepte comme valeur la forme "simplifiée" (non numérique).

--
cordialement
david cobac

Bon, tout ça c'est du pesage de patates et chacun a ses préférences.
Bon développement avec Tk !
-+- ulis in fr.comp.lang.tcl -+-

Xavier Garreau

unread,
Jul 20, 2006, 12:20:52 PM7/20/06
to
Bonjour,

>> Disons que l'écriture entière avec un 0 devant est celle qui a été
>> adoptée pour les octaux. Je pense que c'est tout à fait criticable (pour
>> un novice comme moi).
>> Je me suis jamais servi des octaux, je suis effectivement comme bon nombre
>> de personnes tombé sur cette erreur en manipulant l'heure.
>
> Ah, je suis pas le seul alors !
>
> En tout cas, criticable ou pas je pense qu'on va devoir en faire notre
> deuil. Le TCT ne va probablement jamais corriger ça, ne serait-ce que
> pour conserver la compatibilité des anciens scripts.
>
> Dommage, parce que c'est vraiment idiot !
>

Et le pire c'est que ce n'est ni nouveau ni tclien.

En C le troisième paramètre à open ce sont les droits. Si on n'utilise
pas les constantes, on passe par exemple 0666 ou 04755 le 0 initial,
c'est aussi pour dire octal.

C'est l'erreur classique du débutant qui ne comprends pas pourquoi open
avec 666 ne lui fait pas rw-r--r-- mais -w---x--- (en fait ça donnerait
rw-rw-rw- -w--wx-w- mais avec umask à 0022, on perd bien les 2 w de la
fin :))

zazou$ cat > test.c
#include <fcntl.h>

int main(void) {
close (open ("./titi", O_CREAT | O_RDWR, 666));
close (open ("./toto", O_CREAT | O_RDWR, 0666));
}
zazou$ gcc -o test test.c Pegase:~ zazou$ ./test
zazou$ ls -l t?t?
--w---x--- 1 zazou zazou 0 Jul 20 18:15 titi
-rw-r--r-- 1 zazou zazou 0 Jul 20 18:15 toto

a+
--
Xavier Garreau
http://www.xgarreau.org/

Eric Hassold

unread,
Jul 20, 2006, 12:21:41 PM7/20/06
to
david cobac a écrit :

> une autre solution :
> set a [string trimleft $a 0]

Ne pas oublier (par exemple quand on parse l'heure), le cas ou le
trimleft rend une chaine vide (p. ex. si a vaut 0 ou 00). Dans les
variantes, il y a aussi
scan $a %d a
mais avec comme defaut de ne pas se plaindre si a vaut par exemple "09xxx".

Le "set a [expr int($a.0)]" est a utiliser que si on est sur de ce qu'on
injecte comme valeur a "a". Si "a" vient par exemple d'un formulaire,
c'est la porte ouverte a tous les dangers (voir thread actuel "Dangers
of web apps written in Tcl" sur c.l.t).

De meme, "set a [expr {int([format %f $a])}]" n'effectue pas une
validation de l'entree. Dans certains cas, ca peut n'avoir aucune
importance (par exemple, si on sait que a est retourne par un "clock
format" et correspond aux minutes, donc est un nombre valide), mais peut
etre genant sinon.

En fait, difficile (impossible?) a traiter sans risque de cas marginal
en une seule ligne, alors perso, prefere la fonction a inclure dans le
package "mes outils de base pour mes programmes de plus que quelques ligne":

proc int10 {a} {
if {[string length $a]==0} {
# Entree vide. Ce n'est pas un nombre.
error "not a number"
}

set a [string trimleft $a 0]

if {[string length $a]==0} {
# entree pas vide, mais on obtient une chaine vide apres
# le trimleft, donc a ne contenait que des 0
set a 0
}

# On associe de force une representation entiere a l'objet
# retourne. Si a n'est pas une representation valable d'un nombre
# entier, declenche une erreur
incr a 0
}

> Disons que l'écriture entière avec un 0 devant est celle qui a été
> adoptée pour les octaux. Je pense que c'est tout à fait criticable (pour
> un novice comme moi).
> Je me suis jamais servi des octaux, je suis effectivement comme bon nombre
> de personnes tombé sur cette erruer en manipulant l'heure.
>

Pour les unixiens, la representation en octal est incontournable
historiquement pour les permissions. Par exemple:
file attributes monfichier.txt -permissions 0644
ou le "0644" n'est pas un chaine magique propre a l'argument
"-permissions", mais bien un entier, sous une forme pratique pour gerer
un masque binaire (comme l'ai le format hexa, plus communement).

Et, soit dit en passant, que ce soit bien ou pas, Tcl herite juste d'une
syntaxe commune a tout plein d'autres langages, y compris C:

#include <stdio.h>
int main (int argc, char **argv)
{
int a;

a = 0100;
printf ("a=%d\n",a);
return 0;
}

=> 64

Eric

-----
Eric Hassold
Evolane - http://www.evolane.com/

Kroc

unread,
Jul 21, 2006, 4:10:55 AM7/21/06
to
Eric Hassold a écrit :

> .../...


> Pour les unixiens, la representation en octal est incontournable
> historiquement pour les permissions. Par exemple:
> file attributes monfichier.txt -permissions 0644

On peut tout à fait continuer d'utiliser des octaux pour les
permissions sans pour autant considérer comme octal tout nombre qui
commence par 0.

Qui plus est, considérer par défaut que 07 est un octal : passe
encore, mais pour 08 c'est idiot !

Autre chose ridicule :

% set a 00644
% incr a
421

Là aussi, la logique voudrait que Tcl retourne 00645 : quitte à
prendre de l'octal par défaut, on retourne un octal ! (remarque
valable pour les hexas d'ailleurs). Mais je suppose qu'on atteind là
les limites d'un langage aux variables non typées.

> Et, soit dit en passant, que ce soit bien ou pas, Tcl herite juste d'une

> syntaxe commune a tout plein d'autres langages, y compris C.

J'attends de mon langage de programmation préféré qu'il soit mieux
que les autres, pas qu'il copie leurs absurditées !

david cobac

unread,
Jul 21, 2006, 7:31:55 AM7/21/06
to
Kroc a écrit :
>[...]

> Qui plus est, considérer par défaut que 07 est un octal : passe
> encore, mais pour 08 c'est idiot !

peut-être mais c'est pas forcément illogique...
toute expression susceptible d'être évaluée par expr et qui commence par
0 sera considéré comme un octal...maintenant à l'utilisateur de faire en
sorte de fournir un octal valide.
C'est certain que pour les hexas, c'est plus simple, l'écriture avec le
Ox est sans ambiguïté.

> Autre chose ridicule :
>
> % set a 00644
> % incr a
> 421
>
> Là aussi, la logique voudrait que Tcl retourne 00645 : quitte à
> prendre de l'octal par défaut, on retourne un octal ! (remarque

> valable pour les hexas d'ailleurs).[...]

Oui c'es(t vrai que c'est un peu dommage que expr ne formate pas auto.
la sortie comme l'est l'entrée, maintenant c'est vrai qu'on peut
additionner des entiers écrits dans des bases différentes. Le choix d'un
format de sortie décimale n'est pas finalement illogique, non ?

>
> J'attends de mon langage de programmation préféré qu'il soit mieux
> que les autres, pas qu'il copie leurs absurditées !

c'est un troll ? ;)

--
cordialement
david cobac

Mais c'est expliqué là : http://wfr.tcl.tk/contexte, sous le titre
"la magie du if" (on entend déjà la mer et le cri des cocotiers).
Et Tcl triche (si, si, c'est écrit).

Kroc

unread,
Jul 21, 2006, 7:50:52 AM7/21/06
to
david cobac a écrit :

> Oui c'es(t vrai que c'est un peu dommage que expr ne formate pas auto.
> la sortie comme l'est l'entrée, maintenant c'est vrai qu'on peut
> additionner des entiers écrits dans des bases différentes. Le choix d'un
> format de sortie décimale n'est pas finalement illogique, non ?

La logique devrait être de formater la sortie comme l'entrée lorsque
tous les arguments utilisent une seule et même base et de ne passer en
décimal que lorsqu'il y a plus d'une base en entrée. Non ?

> > J'attends de mon langage de programmation préféré qu'il soit mieux
> > que les autres, pas qu'il copie leurs absurditées !
>
> c'est un troll ? ;)

Non : un gobelin :-D

Xavier Garreau

unread,
Jul 21, 2006, 9:19:08 AM7/21/06
to
>> Oui c'es(t vrai que c'est un peu dommage que expr ne formate pas auto.
>> la sortie comme l'est l'entrée, maintenant c'est vrai qu'on peut
>> additionner des entiers écrits dans des bases différentes. Le choix d'un
>> format de sortie décimale n'est pas finalement illogique, non ?
>
> La logique devrait être de formater la sortie comme l'entrée lorsque
> tous les arguments utilisent une seule et même base et de ne passer en
> décimal que lorsqu'il y a plus d'une base en entrée. Non ?

En fait, il faudrait un langage à typage _et_ formatage dynamique ...

>>> J'attends de mon langage de programmation préféré qu'il soit mieux
>>> que les autres, pas qu'il copie leurs absurditées !
>> c'est un troll ? ;)
>
> Non : un gobelin :-D
>

Poilu quand même le gobelin ...

Eric Hassold

unread,
Jul 21, 2006, 10:07:15 AM7/21/06
to
Kroc a écrit :

> Autre chose ridicule :
>
> % set a 00644
> % incr a
> 421
>
> Là aussi, la logique voudrait que Tcl retourne 00645 : quitte à
> prendre de l'octal par défaut, on retourne un octal ! (remarque
> valable pour les hexas d'ailleurs). Mais je suppose qu'on atteind là
> les limites d'un langage aux variables non typées.
>


Octal ou hexa ne sont pas des types, ce sont des representations
syntaxiques d'objets du type entier. De meme que 1e3 ou 1000.0 sont des
representations disctinctes d'objets du type float.

Bon, bien sur, on pourrait imaginer alourdir la structure Tcl_Obj pour
qu'elle encapsule un format dynamique a utiliser pour afficher
l'affichage. Mais bon, en attendant, apprecie la flexibilite de Tcl sur
le sujet, quitte a prendre soin d'appeler explicitement le "format %d"
ou "format %05o" qu'il faut, qd il faut.

>
> J'attends de mon langage de programmation préféré qu'il soit mieux
> que les autres, pas qu'il copie leurs absurditées !
>

Belle illustration du "qui aime bien chatie bien" ;-) Allez, disons que
Tcl a les defauts de ses qualites :-) Tcl n'a pas la rigueur semantique
de ocaml (par ex.) ou n'est pas autant generique de C. Perso,
j'affectionne de pouvoir qualifier chacun des trois de "mon langage
prefere" selon circonstances (i.e. projets).

Eric

Kroc

unread,
Jul 21, 2006, 11:12:00 AM7/21/06
to
Eric Hassold a écrit :

> Octal ou hexa ne sont pas des types, ce sont des representations
> syntaxiques d'objets du type entier.

Mea culpa.

> Bon, bien sur, on pourrait imaginer alourdir la structure Tcl_Obj pour
> qu'elle encapsule un format dynamique a utiliser pour afficher
> l'affichage. Mais bon, en attendant, apprecie la flexibilite de Tcl sur

> le sujet...

N'aie crainte Eric, j'apprécie :-)

> > J'attends de mon langage de programmation préféré qu'il soit mieux
> > que les autres, pas qu'il copie leurs absurditées !
>
> Belle illustration du "qui aime bien chatie bien" ;-)

N'est-ce pas ! ;-)

PS (OT) : pourquoi Evolane ne distribue pas scene sous forme de package
en dehors d'eTcl ? C'est à cause d'une limitation technique, d'un
manque de temps, c'est un choix ?

Eric Hassold

unread,
Jul 21, 2006, 11:45:04 AM7/21/06
to
Kroc a écrit :

> PS (OT) : pourquoi Evolane ne distribue pas scene sous forme de package
> en dehors d'eTcl ? C'est à cause d'une limitation technique, d'un
> manque de temps, c'est un choix ?

Le temps, helas le temps :-( C'est le cas pour l'extension scene, mais
aussi par exemple pour l'extension pixane (manipulation et
transformation d'images depuis Tcl, Tk non requis), dont nous sommes
convaincu de l'interet general en dehors de eTcl, mais dont on n'assure
aucune promotion ni distribution opensource uniquement par manque de temps.

En fait, si tu savais le nombre de packages Tcl et extensions C
accumules avec les annees, certaines tout a fait stables, mais dont on
n'ose meme pas mettre les sources en l'etat disponible au
telechargement, juste parce qu'ils manquent d'une documentation decente
(destinee au public, ce qui differe d'une pure documentation technique
parfois acceptable et suffisante en interne, dans une petite equipe). Il
est evident que, a cote du support actif de eTcl et de nos projets
internes pour essayer de manger et payer le loyer, ca laisserait peu
(voire pas) de temps pour repondre aux innombrables questions qui se
poseraient comme "la compilation echoue sur ma machine XXX avec mon
compilo YYY" et autres "comment fait ont pour ...".

La (non-)solution qui s'est imposee est un peu radicale, helas. Avec
optimisme, me dis que peut-etre le mois d'aout, et son tempo un peu
moins frenetique, sera une bonne periode pour donner une vitrine a tous
ces composants, meme quitte a les livrer "en vrac". Il sera alors
possible d'identifier ceux qui suscitent le plus d'interet de la
communaute, et au moins pour cela trouver peut-etre le temps de "soigner
l'emballage".

Tiens, dans le genre code pas forcement utile, pas du tout documente,
mais joli exercice de Tcl pouvant tout faire, comme on semble les
affectionner sur ce groupe, j'ai un decompresseur ZIP en pure Tcl. A
cote des jeux sur le nombres de commandes ou variables, ca amuse qq'un
de jouer au jeu de la meilleure performance?

Eric

0 new messages