---

Har lige følgende problem jeg ikke forstår:
   char confirm[4];
      do {
         #if defined(DEBUG)
            printf("\nDEBUG MSG: Found previous answer as %c.\n", confirm[0]);
         #endif
         sleep(1);
         printf("Want to save? (Y/N): ");         
         fgets(confirm, 4, stdin);
         confirm[strlen(confirm)-1] = '\0';
      } while(confirm[0] != 'Y' && confirm[0] != 'y' && confirm[0] != 'N' &&
confirm[0] != 'n');

Når jeg kører denne, så laver den lige den her:
DEBUG MSG: Found previous answer as .

Want to save? (Y/N): <<< Lige her hopper den bare videre
DEBUG MSG: Found previous answer as .

Want to save? (Y/N): h
DEBUG MSG: Found previous answer as h.

Want to save? (Y/N): y
PROGRAM ENDED

Hvorfor laver den lige den første loop hvor den bare hopper igennem

---

Jesper Staun Hansen skrev:

> Har lige følgende problem jeg ikke forstår:
>    char confirm[4];
>       do {
>          #if defined(DEBUG)
>             printf("\nDEBUG MSG: Found previous answer as %c.\n", confirm[0]);
>          #endif
>          sleep(1);
>          printf("Want to save? (Y/N): ");         
>          fgets(confirm, 4, stdin);
>          confirm[strlen(confirm)-1] = '\0';
>       } while(confirm[0] != 'Y' && confirm[0] != 'y' && confirm[0] != 'N' &&
> confirm[0] != 'n');

> Hvorfor laver den lige den første loop hvor den bare hopper igennem

Fordi "#if defined" ikke forstås af compileren?

Jeg bruger være #ifdef (og evt. #ifndef).

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Jesper Staun Hansen skrev:
>
>> Har lige følgende problem jeg ikke forstår:
>>    char confirm[4];
>>       do {
>>          #if defined(DEBUG)
>>             printf("\nDEBUG MSG: Found previous answer as %c.\n", confirm[0]);
>>          #endif
>>          sleep(1);
>>          printf("Want to save? (Y/N): ");         
>>          fgets(confirm, 4, stdin);
>>          confirm[strlen(confirm)-1] = '\0';
>>       } while(confirm[0] != 'Y' && confirm[0] != 'y' && confirm[0] != 'N' &&
>> confirm[0] != 'n');
>
>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>
> Fordi "#if defined" ikke forstås af compileren?
>
> Jeg bruger være #ifdef (og evt. #ifndef).
>
Sludder, #if defined() er standard siden C89 .

En mere sandsynlig årsag er at der er et linjeskift eller 4 støjtegn i
kø i stdin, som så opfattes som svar på først spørgsmål.

Og nej, fflush(stdin) æder ikke den slags, undtagen på visse udgaver af
DOS, hvor det at tømme tastaturkøen blev kaldt flush og derfor blev
rodet sammen med det at tømme I/O buffere og cache (det er det fflush
normalt gør).

P.S.

Linien
> confirm[strlen(confirm)-1] = '\0';
er ikke god nok:

Hvis input er på 0 tegn (f.eks. ved EOF på input) overskrives en byte
uden for arrayet. Hvis input er for langt til bufferen (hvis der f.eks.
indtastes ordet YES), men stadig 0-termineret ædes det sidste
almindelige tegn fordi linieskiftet først returneres i næste kald til
fgets(). Og hvis input af uransagelige grunde skulle være utermineret
vil strlen løbe ud over kanten på bufferen og der vil blive skrevet et 0
til et tilfældigt sted i memory!

I det aktuelle program bruges 0-termineringen alligevel ikke, så linien
kan simpelthen undværes.

--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

---

"Bertel Lund Hansen" <unospamo@lundhansen.dk> wrote in message
news:1x9pllnc297z0$.1vjvhdz6uirlr.dlg@40tude.net...
>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>
> Fordi "#if defined" ikke forstås af compileren?
>
> Jeg bruger være #ifdef (og evt. #ifndef).

#if og #ifdef er to forskellige preprocesserdirektiver. Hvorfor giver du
misledende information, når det er så nemt at slå op?

---

>> Jeg bruger være #ifdef (og evt. #ifndef).
>
> Hvorfor giver du misledende information, når det er så nemt at slå op?

Ro på ! Det ligner en omformulering der gik galt.

tpt

---

Jesper Staun Hansen wrote:
> Har lige følgende problem jeg ikke forstår:
> char confirm[4];
> do {
> #if defined(DEBUG)
> printf("\nDEBUG MSG: Found previous answer as %c.\n",
> confirm[0]);
> #endif
> sleep(1);
> printf("Want to save? (Y/N): ");
> fgets(confirm, 4, stdin);
> confirm[strlen(confirm)-1] = '\0';
> } while(confirm[0] != 'Y' && confirm[0] != 'y' && confirm[0] !=
> 'N' && confirm[0] != 'n');
>
> Når jeg kører denne, så laver den lige den her:
> DEBUG MSG: Found previous answer as .
>
> Want to save? (Y/N): <<< Lige her hopper den bare videre
> DEBUG MSG: Found previous answer as .
>
> Want to save? (Y/N): h
> DEBUG MSG: Found previous answer as h.
>
> Want to save? (Y/N): y
> PROGRAM ENDED
>
> Hvorfor laver den lige den første loop hvor den bare hopper igennem

Tilføj en fflush(stdin) i starten af programmet for at tømme stdin, når
du starter.

Mvh
Martin

---

Martin M. Pedersen skrev:

>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>
> Tilføj en fflush(stdin) i starten af programmet for at tømme stdin, når
> du starter.

Man kan ikke flushe en input stream, som f.eks. stdin.
At det ser ud til at "virke" på din computer med din compiler
betyder langt fra at det vil virke på andre computere med
andre compilere.

Løsningen er som altid at bruge fgets til alle læsninger fra
keyboard. Dvs. ingen scanf, getc osv.

--
Just another homepage:
http://damb.dk
But it's mine - Bertel

---

Bertel Brander wrote:
> Martin M. Pedersen skrev:
>
>>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>>
>> Tilføj en fflush(stdin) i starten af programmet for at tømme stdin,
>> når du starter.
>
> Man kan ikke flushe en input stream, som f.eks. stdin.
> At det ser ud til at "virke" på din computer med din compiler
> betyder langt fra at det vil virke på andre computere med
> andre compilere.
>
> Løsningen er som altid at bruge fgets til alle læsninger fra
> keyboard. Dvs. ingen scanf, getc osv.
>
Jamen er det ikke det den oprindelige spørger gør?

mvh
Jesper

---

jespr skrev:
> Bertel Brander wrote:
>> Martin M. Pedersen skrev:
>>
>>>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>>>
>>> Tilføj en fflush(stdin) i starten af programmet for at tømme stdin,
>>> når du starter.
>>
>> Man kan ikke flushe en input stream, som f.eks. stdin.
>> At det ser ud til at "virke" på din computer med din compiler
>> betyder langt fra at det vil virke på andre computere med
>> andre compilere.
>>
>> Løsningen er som altid at bruge fgets til alle læsninger fra
>> keyboard. Dvs. ingen scanf, getc osv.
>>
> Jamen er det ikke det den oprindelige spørger gør?

Hvis man ser i de andre tråde som OP har haft de seneste
dage kan man se at scanf er blevet brugt.
Derfor har jeg en mistanke om at der er en scanf inden
den stump kode vi har set.

--
Just another homepage:
http://damb.dk
But it's mine - Bertel

---

Bertel Brander wrote:
> jespr skrev:
>> Bertel Brander wrote:
>>> Martin M. Pedersen skrev:
>>>
>>>>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>>>>
>>>> Tilføj en fflush(stdin) i starten af programmet for at tømme stdin,
>>>> når du starter.
>>>
>>> Man kan ikke flushe en input stream, som f.eks. stdin.
>>> At det ser ud til at "virke" på din computer med din compiler
>>> betyder langt fra at det vil virke på andre computere med
>>> andre compilere.
>>>
>>> Løsningen er som altid at bruge fgets til alle læsninger fra
>>> keyboard. Dvs. ingen scanf, getc osv.
>>>
>> Jamen er det ikke det den oprindelige spørger gør?
>
> Hvis man ser i de andre tråde som OP har haft de seneste
> dage kan man se at scanf er blevet brugt.
> Derfor har jeg en mistanke om at der er en scanf inden
> den stump kode vi har set.
>
uuu godt spottet, hvis det er tilfældet.

Jespr

---

jespr wrote:
> Bertel Brander wrote:
>> jespr skrev:
>>> Bertel Brander wrote:
>>>> Martin M. Pedersen skrev:
>>>>
>>>>>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>>>>>
>>>>> Tilføj en fflush(stdin) i starten af programmet for at tømme stdin,
>>>>> når du starter.
>>>>
>>>> Man kan ikke flushe en input stream, som f.eks. stdin.
>>>> At det ser ud til at "virke" på din computer med din compiler
>>>> betyder langt fra at det vil virke på andre computere med
>>>> andre compilere.
>>>>
>>>> Løsningen er som altid at bruge fgets til alle læsninger fra
>>>> keyboard. Dvs. ingen scanf, getc osv.
>>>>
>>> Jamen er det ikke det den oprindelige spørger gør?
>>
>> Hvis man ser i de andre tråde som OP har haft de seneste
>> dage kan man se at scanf er blevet brugt.
>> Derfor har jeg en mistanke om at der er en scanf inden
>> den stump kode vi har set.
>>
> uuu godt spottet, hvis det er tilfældet.
>
> Jespr

Man kan sige jeg stadig er under "oplæring", så jeg eksperimenterer med
hvordan de forskellige prototyper reagerer med resten af koden i en
helhed og her finder jeg at der er mange af disse som bare "hopper
videre" af hvad jeg kan se er uden grund, men fik da en forklaring

Jeg undre mig dog lige lidt over at Bertel Brander siger jeg altid skal
bruge den når den hopper således? - Det kunne dog være jeg skulle se
hans svar i forbindelse, at jeg bruger fgets i forbindelse med scanf som
er skøre på hinanden når de bruges efter hinanden.

---

Den Sun, 13 May 2007 12:20:09 +0200 skrev Jesper Staun Hansen:
> jespr wrote:
>> Bertel Brander wrote:
>>> jespr skrev:
>>>> Bertel Brander wrote:
>>>>> Martin M. Pedersen skrev:
>>>>>
>>>>>>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>>>>>>
>>>>>> Tilføj en fflush(stdin) i starten af programmet for at tømme stdin,
>>>>>> når du starter.
>>>>>
>>>>> Man kan ikke flushe en input stream, som f.eks. stdin.
>>>>> At det ser ud til at "virke" på din computer med din compiler
>>>>> betyder langt fra at det vil virke på andre computere med
>>>>> andre compilere.
>>>>>
>>>>> Løsningen er som altid at bruge fgets til alle læsninger fra
>>>>> keyboard. Dvs. ingen scanf, getc osv.
>>>>>
>>>> Jamen er det ikke det den oprindelige spørger gør?
>>>
>>> Hvis man ser i de andre tråde som OP har haft de seneste
>>> dage kan man se at scanf er blevet brugt.
>>> Derfor har jeg en mistanke om at der er en scanf inden
>>> den stump kode vi har set.
>>>
>> uuu godt spottet, hvis det er tilfældet.
>>
>> Jespr
>
> Man kan sige jeg stadig er under "oplæring", så jeg eksperimenterer med
> hvordan de forskellige prototyper reagerer med resten af koden i en
> helhed og her finder jeg at der er mange af disse som bare "hopper
> videre" af hvad jeg kan se er uden grund, men fik da en forklaring
>
> Jeg undre mig dog lige lidt over at Bertel Brander siger jeg altid skal
> bruge den når den hopper således? - Det kunne dog være jeg skulle se
> hans svar i forbindelse, at jeg bruger fgets i forbindelse med scanf som
> er skøre på hinanden når de bruges efter hinanden.

Det er såmænd ikke at de "er skøre på hinanden", du skal bare passe
på med hvor meget du læser. Det du ikke læser vil stadig ligge i
bufferen til næste gang.

Fx hvis du taster "test" <enter>, og læser "test", hvad er der så
tilbage? <Enter> er bare et tegn som alle andre, og hvis den stadig
ligger i bufferen når du når til fgets, vil den blot læse en tom
streng.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Den Sun, 13 May 2007 12:20:09 +0200 skrev Jesper Staun Hansen:
>> jespr wrote:
>>> Bertel Brander wrote:
>>>> jespr skrev:
>>>>> Bertel Brander wrote:
>>>>>> Martin M. Pedersen skrev:
>>>>>>
>>>>>>>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>>>>>>> Tilføj en fflush(stdin) i starten af programmet for at tømme stdin,
>>>>>>> når du starter.
>>>>>> Man kan ikke flushe en input stream, som f.eks. stdin.
>>>>>> At det ser ud til at "virke" på din computer med din compiler
>>>>>> betyder langt fra at det vil virke på andre computere med
>>>>>> andre compilere.
>>>>>>
>>>>>> Løsningen er som altid at bruge fgets til alle læsninger fra
>>>>>> keyboard. Dvs. ingen scanf, getc osv.
>>>>>>
>>>>> Jamen er det ikke det den oprindelige spørger gør?
>>>> Hvis man ser i de andre tråde som OP har haft de seneste
>>>> dage kan man se at scanf er blevet brugt.
>>>> Derfor har jeg en mistanke om at der er en scanf inden
>>>> den stump kode vi har set.
>>>>
>>> uuu godt spottet, hvis det er tilfældet.
>>>
>>> Jespr
>> Man kan sige jeg stadig er under "oplæring", så jeg eksperimenterer med
>> hvordan de forskellige prototyper reagerer med resten af koden i en
>> helhed og her finder jeg at der er mange af disse som bare "hopper
>> videre" af hvad jeg kan se er uden grund, men fik da en forklaring
>>
>> Jeg undre mig dog lige lidt over at Bertel Brander siger jeg altid skal
>> bruge den når den hopper således? - Det kunne dog være jeg skulle se
>> hans svar i forbindelse, at jeg bruger fgets i forbindelse med scanf som
>> er skøre på hinanden når de bruges efter hinanden.
>
> Det er såmænd ikke at de "er skøre på hinanden", du skal bare passe
> på med hvor meget du læser. Det du ikke læser vil stadig ligge i
> bufferen til næste gang.
>
> Fx hvis du taster "test" <enter>, og læser "test", hvad er der så
> tilbage? <Enter> er bare et tegn som alle andre, og hvis den stadig
> ligger i bufferen når du når til fgets, vil den blot læse en tom
> streng.
>
> Mvh
> Kent

Ja, så derfor burde jeg vel helt undgå at bruge scanf, da hvis den
ligger sig ind i bufferen, vil den bare gøre i det uendelige? eller?

---

Den Sun, 13 May 2007 19:49:20 +0200 skrev Jesper Staun Hansen:
> Kent Friis wrote:
>> Den Sun, 13 May 2007 12:20:09 +0200 skrev Jesper Staun Hansen:
>>> jespr wrote:
>>>> Bertel Brander wrote:
>>>>> jespr skrev:
>>>>>> Bertel Brander wrote:
>>>>>>> Martin M. Pedersen skrev:
>>>>>>>
>>>>>>>>> Hvorfor laver den lige den første loop hvor den bare hopper igennem
>>>>>>>> Tilføj en fflush(stdin) i starten af programmet for at tømme stdin,
>>>>>>>> når du starter.
>>>>>>> Man kan ikke flushe en input stream, som f.eks. stdin.
>>>>>>> At det ser ud til at "virke" på din computer med din compiler
>>>>>>> betyder langt fra at det vil virke på andre computere med
>>>>>>> andre compilere.
>>>>>>>
>>>>>>> Løsningen er som altid at bruge fgets til alle læsninger fra
>>>>>>> keyboard. Dvs. ingen scanf, getc osv.
>>>>>>>
>>>>>> Jamen er det ikke det den oprindelige spørger gør?
>>>>> Hvis man ser i de andre tråde som OP har haft de seneste
>>>>> dage kan man se at scanf er blevet brugt.
>>>>> Derfor har jeg en mistanke om at der er en scanf inden
>>>>> den stump kode vi har set.
>>>>>
>>>> uuu godt spottet, hvis det er tilfældet.
>>>>
>>>> Jespr
>>> Man kan sige jeg stadig er under "oplæring", så jeg eksperimenterer med
>>> hvordan de forskellige prototyper reagerer med resten af koden i en
>>> helhed og her finder jeg at der er mange af disse som bare "hopper
>>> videre" af hvad jeg kan se er uden grund, men fik da en forklaring
>>>
>>> Jeg undre mig dog lige lidt over at Bertel Brander siger jeg altid skal
>>> bruge den når den hopper således? - Det kunne dog være jeg skulle se
>>> hans svar i forbindelse, at jeg bruger fgets i forbindelse med scanf som
>>> er skøre på hinanden når de bruges efter hinanden.
>>
>> Det er såmænd ikke at de "er skøre på hinanden", du skal bare passe
>> på med hvor meget du læser. Det du ikke læser vil stadig ligge i
>> bufferen til næste gang.
>>
>> Fx hvis du taster "test" <enter>, og læser "test", hvad er der så
>> tilbage? <Enter> er bare et tegn som alle andre, og hvis den stadig
>> ligger i bufferen når du når til fgets, vil den blot læse en tom
>> streng.
>
> Ja, så derfor burde jeg vel helt undgå at bruge scanf, da hvis den
> ligger sig ind i bufferen, vil den bare gøre i det uendelige? eller?

Jeg prøver lige igen...

Fx hvis du taster "test" <enter>, og læser "test", hvad er der så
tilbage? <Enter> er bare et tegn som alle andre, og hvis <enter>
stadig ligger i bufferen når du når til fgets, vil fgets blot læse
en tom streng, da fgets kun læser hen til og med <enter>.

Så skulle der ikke være noget tvetydige ord som "den".

Det har som sådan ikke noget med scanf at gøre, det er hvilke tastetryk
der ligger i bufferen det kommer an på.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).