Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C transformer un tampon en lignes

transformer un tampon en lignes

56 réponses
Avatar
Benoit Izac
Bonjour,

Je cherche à faire une fonction qui me permette de transformer un tampon
en lignes de façon à traiter ces dernières par la suite.

J'ai un bout de code qui fonctionne :
========================================================================
#include <stdio.h>
#include <stdlib.h>

#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

#define BS 10
#define LM 100

int get_line(const char *buffer, size_t *bp, size_t bs,
char *line, size_t *lp, size_t ls)
{
while (*bp < bs) {
/* not enough space in line */
if (!(*lp < ls)) {
(*bp)--;
line[(*lp)-1] = 0;
(*lp) = 0;
return -1;
}
/* end of file? */
if (buffer[*bp] == EOF) {
printf("end of file?\n");
line[*lp] = 0;
return 0;
}
/* end of line */
if (buffer[*bp] == '\n') {
line[*lp] = 0;
(*lp) = 0;
(*bp)++;
return 1;
}
line[*lp] = buffer[*bp];
(*lp)++;
(*bp)++;
}
/* end of buffer */
(*bp) = 0;
line[*lp] = 0;
return 0;
}


int main(int argc, char *argv[])
{
int fd;
size_t r;
char buf[BS];
char line[LM];
size_t bp = 0;
size_t lp = 0;

if (argc != 2)
exit(1);

fd = open(argv[1], O_RDONLY);
if (fd < 0)
exit(2);

while((r = read(fd, buf, BS))) {
while (get_line(buf, &bp, r, line, &lp, LM))
printf("%s\n", line);
}

close(fd);
return 0;
}
========================================================================
PS : Désolé pour ceux qui ne sont pas sous Unix, j'ai bien essayé de
faire la même chose avec fread() mais cette dernière ne me renvoie pas
la taille lu, ce qui pose un problème à la dernière lecture où r est la
plupart du temps différent de BS.

Mon choix lorsque la taille de line est trop petite est discutable
(vaut-il mieux tronquer les lignes ?) mais ce n'est pas vraiment ce qui
me pose problème.

Les questions :
* Ce code est-il correct (fonctionne-t-il dans tous les cas) ?
* Est-il possible d'alléger le code (que get_line est moins
d'arguments) en déclarant bp et lp static ?
* Existe-t-il une autre solution (fonction toute faite, autre
algorithme) ?

Merci.
--
Benoit Izac
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
2 3 4 5 6
Avatar
xtof pernod
Le 31/07/2010 15:51, Samuel DEVULDER a fait rien qu'à écrire:
Benoit Izac a écrit :
Bonjour,

le 31/07/2010 à 00:19, xtof pernod a écrit dans le message
<4c535001$0$10191$ :

Je vois bien. Le pb a pourtant pas l'air compliqué, je pense que 10
lignes
de codes devraient suffire, à moins que j'ai loupé un truc.

Faut dire aussi que les infos arrivent un peu au compte-goutte..



Faut pas exagérer non plus. Je reconnais que je me suis viandé avec
fread(), ce qui a provoqué plus de réponses concernant read/open que sur
le problème en lui-même.



Oui c'est l'un des problèmes que je constate aussi avec les piliers du
groupes (les "experts" pour résumer).



Tu veux dire, ceux qui détiennent la Science totale & absolue ?
Bah, c'est un phénomène récurrent sur tout ng.. Non ?

Ils se focalisent sur des détails
sans comprendre le (ou sans vouloir répondre au) sens de la question.



Ah, ça s'est vu, donc.

Cela crée tout de suite des fils à rallonge (vive les querelles
d'experts)



+1

qui ne causent même plus du problème d'origine et qui sont
complètement imbuvables.



+2

C'est sur que pinailler sur un point technique



+3

qui n'est pas le fond du problème est très facile et montre sa profond
compétences des différents aspects et entremêlement des standards, et
aspects systèmes (bravo aux experts!)



+4/3pi.r³

mais c'est parfois hors de propos
et n'aide en rien le posteur originel. +42



Pinaise. J'eusse dû lire cela avant de répondre à l'un des piliers du
Temple, couramment en fonction..

J'ai proposé la fosse à troll, mais le gars a pris peur. Pourtant..

Exemple typique au lieu de répondre à la question "est-ce qu'on peut
simplifier l'API de la fonction?" , ca part sur des dérives au sujet de
open et ses includes et autres 0666 (number of the beast) complètement
hors de sujet.



Je me sens pas du tout visé =) Et en plus, [*]..


Beaucoup oublient que parfois un bout de code ecrit sur le NG n'est pas
le code reel mais qu'il n'est la que pour fixer les idées. Dans la vraie
vie les codes C sont beaucoup plus gros que les 10-15 lignes qu'on ne
peut décemment poster sur une newsgroup et il est normal voir obligé de
shunter des détails important pour l'appli complète (includes par
exemple) mais pas pour le pb spécifique qui coince.

De toute façon à voir les fils les plus long, donc les points les plus
typiquement discutés sur le NG j'aurais l'impression que faire du C
revient super souvent à lire des trucs via le flux standard en
environnement unix et effectuer quelques traitement sur les chaines de
caractères. Heureusement que la programmation (et ses bugs) est beaucoup
plus riche et intéressante que cela avec pleins d'api et de traitements
variés. Du reste, quand on prend du recul, le truc qui coince sur des
petits exemples est souvent à trouver dans la logique du prog (var pas
initialisée, break mal placé, etc) que de condition d'execution rares
telles que "fread() n'a pas tout lu",ou "malloc a echoué", il te manque
tel include en environnement XYZ, etc.

Oulala, je sens que ce que j'écris peut être mal interpréter si on ne
prend pas de recul et qu'on reste attaché aux détails. Aussi je
m'empresse de préciser que parfois oui il est normal d'avoir l'avis des
experts sur les points techniques quand c'est l'endroit qui pose
problème. Mais de là à voir des querelles d'expert sur chaque fil, il y
a de la marge.



Hanc marginis non caparet, attention, y'a des puristes aussi dans les
langues mortes.

Je note juste que l'OP semble se désinteresser de sa question ?


Il faudrait trouver un truc, une notation, pour indiquer qu'un bout de
code est a prendre oui ou non au pied de la lettre auquel cas les
experts peuvent s'en donner à coeur joie. Mais si la notation indique
que c'est un exemple pour fixer les idées, alors de grâce qu'ils passent
outre les simplifications et abus dans le code et se concentrent sur le
pb qui coince vraiment.

sam.




Vous gagnez ton poids en Guinness. A retirer au ng kivabien(tm).

--
christophe. [*] Non rien.
Avatar
Benoit Izac
Bonjour,

le 31/07/2010 à 19:32, Marc Espie a écrit dans le message
<i31mn4$1k5q$ :

J'ai fait quelques tests et offset est différent de zéro lorsque le
buffer était trop petit pour contenir tout le fichier (peut-être qu'il
y a un trou au milieu, je ne sais pas le voir). Donc si il est
égal à 0 : début d'un fichier sinon toujours dans le même fichier.
Mais en fait, je n'ai pas à m'occuper d'offset puisque la fonction me
renvoie ARCHIVE_EOF à la fin du fichier.



Essaie d'archiver avec tar un gros blocs de zeros, tu devrais voir un trou
si tout va bien.

Tu doit t'occuper d'offset de facon minimale, ou sinon, tu risques de
ne pas voir ce genre de probleme.

C'est tres con a faire. Suffit de mettre qq chose genre

predict_offset = 0;

while (archive_read_data_block( ... &size, &offset, ) == ARCHIVE_OK) {
if (offset == predict_offset) {
/* tout va bien */
} else {
/* tiens, un trou */
}

predict_offset = offset + size;
}



Ce n'est pas ce que je constate : dans le cas d'un fichier avec des
trous, l'adresse buff ne change pas et dans tous les cas, j'ai
offset_suivant = len + offset :

###### sparse-file ######
buff 34233440 len 48640 offset 0
buff 34230704 len 2048 offset 48640
buff 34230704 len 2048 offset 50688
[...]
buff 34230704 len 2048 offset 5238272
buff 34230704 len 2048 offset 5240320
buff 34230704 len 512 offset 5242368

le tar a été créé par :
$ dd if=/dev/zero of=sparse-file bs=1k count=0 seekQ20
$ tar cf a.tar sparse-file

--
Benoit Izac
Avatar
Benoit Izac
Bonjour,

le 31/07/2010 à 20:03, xtof pernod a écrit dans le message
<4c546582$0$5425$ :

Je note juste que l'OP semble se désinteresser de sa question ?



Pas du tout, mais en l'absence de réponse, j'en conclus que ma solution
initiale n'était pas si mal (bien qu'elle comportait des erreurs).

J'ai essayé en passant des pointeurs sur des struct mais je trouve cela
encore plus lourd. Le static pose effectivement des problèmes : j'ai
essayé en appelant la fonction sur deux tampons différents en même temps
et bien ça ne marche pas bien.

Je suis toujours intéressé par une solution générique car l'utilisation
d'archive_read_data_block() ne change pas le problème, j'ai toujours un
buffer qui contient une partie du fichier et je fais des analyses sur
des lignes comme je le ferais après des fgets().

--
Benoit Izac
Avatar
espie
In article ,
Benoit Izac wrote:
Ce n'est pas ce que je constate : dans le cas d'un fichier avec des
trous, l'adresse buff ne change pas et dans tous les cas, j'ai
offset_suivant = len + offset :

###### sparse-file ######
buff 34233440 len 48640 offset 0
buff 34230704 len 2048 offset 48640
buff 34230704 len 2048 offset 50688
[...]
buff 34230704 len 2048 offset 5238272
buff 34230704 len 2048 offset 5240320
buff 34230704 len 512 offset 5242368

le tar a été créé par :
$ dd if=/dev/zero of=sparse-file bs=1k count=0 seekQ20
$ tar cf a.tar sparse-file



Faudrait que je me plonge plus en detail dans libarchive, ce que je
ne ferai pas. Il est fort possible que la gestion des trous ne soit
faite que pour certains formats d'archives. C'est essentiellement une
fonctionnalite un peu antique, qui tombe peu a peu en desuetude...
Avatar
Samuel DEVULDER
Marc Espie a écrit :
In article <4c544fa1$0$17434$,
Samuel DEVULDER wrote:
strtok maintient un buffer interne, c'est evidemment pas super. Autant
utiliser strtok_r ou re-écrire cette fonction soi-même (c'est pas
difficile) et utiliser une structure passée en argument pour y stocker
les choses persistantes.

Je pense que vu la tournure de l'informatique actuelle, il va falloir
apprendre à programmer thread-safe de plus en plus souvent (fini les
Ghz, bonjour les multi-coeurs).



Vu que le programmeur moyen ne sait meme pas programmer sans bugs sur
du mono-thread, c'est pas gagne.



Il faut peut être ne plus utiliser de "programmeurs". C'est un terme
trop générique pour décrire honnêtement l'ensemble des métiers et
compétences nécessaires à la fabrication d'un logiciel.

Je ne sais pas si dans les écoles on apprends concrètement la façon de
*concevoir* et pas simplement coder les logiciels, mais ca ne serait pas
du luxe (il faut les bons enseignants derrière bien entendu). Apprendre
à travailler en équipe sur le même logiciel dans des versions
différentes avec des plan de test, de la gestion de conf est aussi un
truc important pour le boulot.

Que ce soit la gestion des semaphores ou l'apprentissage des algo
"lockless", c'est de la vraie informatique.



oui et c'est super intéressant.

Et on a de moins en moins de vrais informaticiens.



Il faudrait peut-être regarder du coté des électroniciens. Les systèmes
électroniques actuels sont des trucs intrinsèquement parallèles conçu en
équipes avec des notions de précise de ce qu'on demande au circuit de
faire, de testabilité et de modularité qu'on ne trouve pas partout en
informatique. Au final ce qu'ils font ne marche pas trop mal tout compte
fait.

Par ailleurs je sais qu'il existe des gens qui pensent que
l'informatique est devenue trop complexe et bourrée de cas particuliers
et qui ont pour objectif de refaire ce qui se fait en informatique
(langage de programmation, structures de données, GUI) mais avec des
concepts beacoup plus propres et simples. Ainsi ils arrivent à écrire
des compilos qui tiennent dans quelques centaines de lignes de source
seulement (parseur, optimiseur et génération de binaire inclus je
crois), ou une pile TCP/IP complète directement depuis le texte de la
RFC en quelque pages. C'est peut être aussi une solution: re-concevoir
l'informatique pour etre plus simple, plus modulaire, plus efficace.

Je ne connais pas complètement leur travaux, mais un collègue m'a passé
l'un de leur article "Chains of Meaning in the STEPS system)", Ian
PIUMARTA, ViewPoint Research Institute
(http://www.vpri.org/pdf/m2009011_chns_mng.pdf).

Mais Joel Spolski a pondu le texte ultime sur le sujet:

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html



Merci, je vais le lire.

a+

sam.
Avatar
espie
In article <4c5470d9$0$31085$,
Samuel DEVULDER wrote:
Je ne connais pas complètement leur travaux, mais un collègue m'a passé
l'un de leur article "Chains of Meaning in the STEPS system)", Ian
PIUMARTA, ViewPoint Research Institute
(http://www.vpri.org/pdf/m2009011_chns_mng.pdf).



Ca peut pas etre completement mauvais. Je soupconne que tu connais Ian,
comme moi, comme etant l'un (sinon le principal) responsable de l'adaptation
de Squeak a Unix.
Avatar
Samuel DEVULDER
Benoit Izac a écrit :

J'ai essayé en passant des pointeurs sur des struct mais je trouve cela
encore plus lourd.



Ne passes pas plusieurs pointeurs. Passes en un seul, sur la structure
kivabien avec les sous structures pour tes entrées, tes sorties, et tes
vars d'état. Si la structure de donnée est bonne, le code devrait en
être simplifié. Enfin en général c'est plutôt l'inverse (quand la
structure est mauvaise, le code est moche autour), mais ca veut dire la
même chose.

Je suis toujours intéressé par une solution générique car l'utilisation
d'archive_read_data_block() ne change pas le problème, j'ai toujours un
buffer qui contient une partie du fichier et je fais des analyses sur
des lignes comme je le ferais après des fgets().



Est-ce que tu n'aurais besoin de la notion de stream. Un truc capable de
te fournir des caractères un à un. C'est vraiment de l'OO, mais ca doit
se faire en C aussi (FILE* est un stream).

Peut être qu'en écrivant ton code de sorte à ce qu'il prennent en
argument (ou dans la struct dont je fais référence) une fonction dont le
contrat est de te présenter les data d'une certaine façon pour que ton
algo marche indiférrement entre un fgets(), un truc venant d'un fichier
tgz ou autre. Ensuite à toi d'écrire cette couche d'adaptation de depuis
ton format d'entrée pour produire les données dont a besoin ton algo,
cette adaptation étant faire indépendamment de l'algo de découpage initial.

Oui je sais on se rapproche dangereusement de la POO avec ce mélange de
data et de méthodes.. mais tout n'est pas à jeter dans l'OO.

sam.
Avatar
xtof pernod
Le 31/07/2010 20:15, Benoit Izac a fait rien qu'à écrire:
le 31/07/2010 à 20:03, xtof pernod a écrit dans le message
<4c546582$0$5425$ :

Je note juste que l'OP semble se désinteresser de sa question ?



Pas du tout, mais en l'absence de réponse,



Pinaise, je sais vraiment pas ce qu'il te faut..

j'en conclus que ma solution
initiale n'était pas si mal (bien qu'elle comportait des erreurs).



Comme tu le sens ! La science progresse aussi par tâtonnements, et
on apprend bien autant avec les erreurs qu'avec du pré-mâché.


J'ai essayé en passant des pointeurs sur des struct mais (...)



Bon, je te laisse avec les gens compétents qui apparemment sont éveillés.
Bonne chance,

--
christophe.
Avatar
Gabriel Dos Reis
xtof pernod writes:

| T'as bien raison, j'avoue, j'y pane que pouic à tout ce bazard octal.
| Heureusement, tu es là, et tu réponds merveilleusement au probl ème
| posé par l'OP.
|
| Juste, pourquoi t'as pas pris la peine de lui répondre ?

Réponse : voir la phrase précédente.
Avatar
Gabriel Dos Reis
Samuel DEVULDER writes:

[...]

| Beaucoup oublient que parfois un bout de code ecrit sur le NG n'est
| pas le code reel mais qu'il n'est la que pour fixer les idées.

si le code posté contient des incorrections, il ne fixe pas grandes id ées,
excepté montrer qu'on a effectivement un problème.
2 3 4 5 6