[Prog] C: een relationele liedjesdatabase

[dragonstorm]

Ik heb een (minimale) relationele database voor liedjes gemaakt, maar hij kent 1 bug; de albumnamen worden dubbel ingevoerd!

de sourcecode staat op:

http://home.kabelfoon.nl/~bwiegm/songdb.tar.bz2

graag hulp, want ik weet t echt niet meer

[GVR]

Ik snap niet echt wat je bedoel met albumnamen worden dubbel ingelezen, maar heb wel alvast anderhalve andere bugs voor je gevonden:

1. In readline als !(i < length) wordt s[i] = '\0' geschreven met i op length (dus een er voorbij). Dit kan je beter oplossen met een if-je als:
if (++i >= length ) { --i; break }

1.5. typedef char* string is vies en maakt dingen onnodig onduidelijk. het suggereert dat string iets speciaals is terwijl het gewoon een char* is.

1.7. Voor alle andere typedefs die van pointers aparte namen maakt geldt hetzelfde. Het maakt de code onnodig onleesbaar.

Verder geeft gcc -Wall -g3 nog 2 foutjes, main returned niks en ergens zit een onduidelijk
if() if() {} else {}
Beide niet relevant zover ik kan zien.

[dragonstorm]

typedef char * geeft een flexibiliteit, nl als ik ooit unicode chars wil gebruiken, is dat maar 1 regel code aanpassen

idem voor andere typedefs..

maar ik zal er naar kijken

[GVR]

dragonstorm schreef op 12-08-2005 @ 22:05 :
typedef char * geeft een flexibiliteit, nl als ik ooit unicode chars wil gebruiken, is dat maar 1 regel code aanpassen

idem voor andere typedefs..

maar ik zal er naar kijken

Het is al UTF-8

[dragonstorm]

eh.... serieus? als ik het compileer met gnu gcc 3.4.3 (versie van slack 10.1), heb ik dan direct unicode support? relaxed...

ik kan op dit moment niet bij de sourcecode, maar ik weet iig dat in de code voor het verwijderen van een element kans is op een memory leak: als je een listhead verwijderd, word de bijbehorende naamstring niet verwijderd en de lijst die erbij hoort ook niet.... foutje

[GVR]

dragonstorm schreef op 16-08-2005 @ 22:44 :
eh.... serieus? als ik het compileer met gnu gcc 3.4.3 (versie van slack 10.1), heb ik dan direct unicode support? relaxed...

Niet helemaal UTF-8 Level 1 (of zoiets). ASCII(0-127) mapped namelijk 1:1 met UTF-8. Maar de str* functies kunnen niet met UTF-8 Level > 1 omdat je dan multibyte charachters krijg die \0 kunnen bevatten en omdat bv strlen's returnvalue onduidelijk wordt (karakters of bytes?).

Heb je inmiddels je probleem al opgelost?

[dragonstorm]

nope, ben week op vakantie geweest, daarom kon ik ook niet bij de source maar deze bug schoot me te binnen......
ik weet ook niet of ik er morgen aan kan werken (ga naar lowlands ) maar ik post t wel als k zie wat t was

edit:

*huilt*. de bug is er _alleen_ bij een paar cd's, zoals superunknown - de titel 'commit this to memory' word gewoon goed verwerkt, evenals 'version 2.0'

[dragonstorm]

het lijkt op een fout met glibc:

na 3 maal 'superunknown' invoeren krijg ik een fout met 'glibc: free(): invalid size'

na 3 maal 'commit this to memory' invoeren doettie t prima

nou ja, ik ga het hercompileren op een andere (oudere versie van glibc) computer, en dan kijken wat er gebeurt

[GVR]

dragonstorm schreef op 23-08-2005 @ 20:44 :
het lijkt op een fout met glibc:

na 3 maal 'superunknown' invoeren krijg ik een fout met 'glibc: free(): invalid size'

na 3 maal 'commit this to memory' invoeren doettie t prima

nou ja, ik ga het hercompileren op een andere (oudere versie van glibc) computer, en dan kijken wat er gebeurt

Is waarschijnlijk geen fout van libc, je schijf buiten (voor?) je stukjes geheugen. Daar zit een stukje gegevens van de malloc/free functies (een linked list als ik me niet vergis) die je overschrijf. Draai je programma eens in gdb.

[dragonstorm]

well, op m'n 486 met een oude versie van glibc doettie t nie

(hoewel hij 'm 1 keer te veel alloceerd, dat is)

maar ik zal er nog 'ns goed naar kijken

[dragonstorm]

ahem...

kleine fout in cleanstring()

gefixed nu