---

Hej NG.

Jeg er lidt ny ifaget, og mangler lidt hjælp. Jeg skal have konverteret 4
char til en long, jeg har lavet et lille testprg. ,men den kommer ikke ud
med det rigtige facit. Hvad gør jeg galt.

Mvh Jens

#include <stdio.h>
#include <conio.h>
#include <string.h>
#include <stdlib.h>

char a=43;
char b=65;
char c=234;
char d=124;
unsigned long nr;

void main(void)
{
nr = (a+(b<<8)+(c<<16)+(d<<24));
printf("%lu",nr);
getch();
}

---

-Uncle- skrev:

>Jeg er lidt ny ifaget, og mangler lidt hjælp. Jeg skal have konverteret 4
>char til en long, jeg har lavet et lille testprg. ,men den kommer ikke ud
>med det rigtige facit. Hvad gør jeg galt.

Char rummer præcis 8 bit, og hvis du skifter den 8 pladser, giver
det enten 0 eller 255.

>void main(void)
>{
> nr = (a+(b<<8)+(c<<16)+(d<<24));
> printf("%lu",nr);
> getch();
>}

int main(void)
{
nr = (((d*256)+c)*256+b)*256+a;
printf("%lu",nr);
getch();

return 0;
}

Prototypen for main() er int. Derfor bør man lave den som int
selv om mange compilere accepterer en void. Den returnerede værdi
er nyttig i nogle situationer.

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

---

On Sun, 13 Apr 2003 19:37:14 +0200, Bertel Lund Hansen
<nospamfor@lundhansen.dk> wrote:

> nr = (((d*256)+c)*256+b)*256+a;

Samme problem, det er ikke måden, men derimod typen.

/Thomas

---

Thomas Lykkeberg skrev:

>Samme problem, det er ikke måden, men derimod typen.

Problem? Det kan BCpp 5.5 ikke få øje på.

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

---

On Sun, 13 Apr 2003 20:14:37 +0200, Bertel Lund Hansen
<nospamfor@lundhansen.dk> wrote:

>Problem? Det kan BCpp 5.5 ikke få øje på.

char a = 243;
unsigned long b;

main()
{
b = (a*256);
}

Hvad bliver b lig med ? Selvfølgelig kan din BCpp ikke finde den
"fejl", hvis man da kan tale om en fejl. Jeg vil nu nærmere mene at
det er en opførsel som Jens (tårdens begynder) ikke havde regnet med.

/Thomas

---

Thomas Lykkeberg skrev:

>Hvad bliver b lig med ? Selvfølgelig kan din BCpp ikke finde den
>"fejl", hvis man da kan tale om en fejl. Jeg vil nu nærmere mene at
>det er en opførsel som Jens (tårdens begynder) ikke havde regnet med.

Du har ret. Det virker mere forståeligt hvis han erklærer
"unsigned char" i stedet for "char".

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

---

Bertel Lund Hansen wrote:

> int main(void)
> {

.....

> return 0;
> }
>
> Prototypen for main() er int. Derfor bør man lave den som int
> selv om mange compilere accepterer en void. Den returnerede værdi
> er nyttig i nogle situationer.

Hvis vi skal hænge os i bagateller skulle det være
return EXIT_SUCCESS;

--
Med venlig hilsen | homepage: http://bo.geekworld.dk
Bo Simonsen | e-mail: bo@geekworld.dk

---

Bo Simonsen skrev:

>Hvis vi skal hænge os i bagateller skulle det være
>return EXIT_SUCCESS;

Hvorfor? Det er det modtagende program der skal reagere på
værdien. Så er det vel ligemeget om jeg eller EXIT_SUCCESS
fastlægger den?

Hvis modtageren selv er et C-program, er konstanten naturligvis
en lille fordel.

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

---

Bertel Lund Hansen wrote:

> Bo Simonsen skrev:
>
>>Hvis vi skal hænge os i bagateller skulle det være
>>return EXIT_SUCCESS;
>
> Hvorfor? Det er det modtagende program der skal reagere på
> værdien. Så er det vel ligemeget om jeg eller EXIT_SUCCESS
> fastlægger den?

Så vidt jeg har forstået, er det hensigtsmæssigt, hvis SUCCESS kreteriet, i
et givent operativ system er noget andet end 0.

--
Med venlig hilsen | homepage: http://bo.geekworld.dk
Bo Simonsen | e-mail: bo@geekworld.dk

---

"Bo Simonsen" <bo@geekworld.dk> wrote in message
news:b7c9is$qmr$1@sunsite.dk...
> Bertel Lund Hansen wrote:
>
> > int main(void)
> > {
>
> ....
>
> > return 0;
> > }
> >
> > Prototypen for main() er int. Derfor bør man lave den som int
> > selv om mange compilere accepterer en void. Den returnerede værdi
> > er nyttig i nogle situationer.
>
> Hvis vi skal hænge os i bagateller skulle det være
> return EXIT_SUCCESS;

Hvis det er bagateller du vil hænge dig i, så er det passende at påpege at

int main()
{
//...
return 0;
}

int main()
{
// ...
return EXIT_SUCCESS;
}

int main()
{
// ...
// exit without return
}

har _fuldstændig_ samme betydning.
Dit indlæg kunne give en anden opfattelse.

Se eventuelt §3.6.1-5 og §18.3-8 i C++ Standarden eller §5.1.2.2.3 og
§7.20.4.3-5 i C99 Standarden for yderligere detaljer.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> int main()
> {
> // ...
> // exit without return
> }
>
> har _fuldstændig_ samme betydning.
> Dit indlæg kunne give en anden opfattelse.

Anyway det er da ikke venligt, overfor compileren, at angive en
returværdien som integer, uden at returnere noget.

--
Med venlig hilsen | homepage: http://bo.geekworld.dk
Bo Simonsen | e-mail: bo@geekworld.dk

---

"Bo Simonsen" <bo@geekworld.dk> wrote in message
news:b7dtdp$s8b$1@sunsite.dk...

[8<8<8<]
> Anyway det er da ikke venligt, overfor compileren, at angive en
> returværdien som integer, uden at returnere noget.

Hvorfor mener du det ?
Det er _fuldstændigt_ velspecificeret hvad der skal ske, og derfor hvordan
compileren skal håndtere situationen.
Compilere har det med ikke at tage tingene personligt.

Dit oprindelige indlæg gav sig ud for at rette bagateller, men kunne nemt
opfattes som at du rent faktisk havde ikke styr på detaljerne. Det kan nemt
skabe forvirring hos en person der siger han er ny i faget.
Den er egentligt ikke længere for mig.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

>> Anyway det er da ikke venligt, overfor compileren, at angive en
>> returværdien som integer, uden at returnere noget.

> Hvorfor mener du det ?
> Det er _fuldstændigt_ velspecificeret hvad der skal ske, og derfor hvordan
> compileren skal håndtere situationen.

Det er korrekt, men derfor er det alligevelle ikke korrekt C, at angive en
returværdi-type uden at returnere noget.

> Dit oprindelige indlæg gav sig ud for at rette bagateller, men kunne nemt
> opfattes som at du rent faktisk havde ikke styr på detaljerne. Det kan
> nemt skabe forvirring hos en person der siger han er ny i faget.

Korrekt.

> Den er egentligt ikke længere for mig.

Nok heller ikke for mig.

--
Med venlig hilsen | homepage: http://bo.geekworld.dk
Bo Simonsen | e-mail: bo@geekworld.dk

---

"Bo Simonsen" <bo@geekworld.dk> wrote in message
news:b7ed61$1t4$1@sunsite.dk...
> Mogens Hansen wrote:

[8<8<8<]
> > Hvorfor mener du det ?
> > Det er _fuldstændigt_ velspecificeret hvad der skal ske, og derfor
hvordan
> > compileren skal håndtere situationen.
>
> Det er korrekt, men derfor er det alligevelle ikke korrekt C, at angive en
> returværdi-type uden at returnere noget.

Jo, det er både korrekt C og korrekt C++ ikke at returnere noget fra "main",
selvom return typen for "main" _altid_ er "int".
Slå det op i de referencer jeg tidligere har angivet hvis du er i tvivl.
Alternativt kan du angive hvorfra du måtte have en anden opfattelse.

Venlig hilsen

Mogens Hansen

---

> Jo, det er både korrekt C og korrekt C++ ikke at returnere noget fra "main",
> selvom return typen for "main" _altid_ er "int".
> Slå det op i de referencer jeg tidligere har angivet hvis du er i tvivl.
> Alternativt kan du angive hvorfra du måtte have en anden opfattelse.
>
> Venlig hilsen
>
> Mogens Hansen
>

Jeg ønsker egentlig ikke at træde mere rundt i dette, og ja, det er
veldefineret at undlade at retunere noget fra main, men om det er en
god idé, er en anden sag, GCC og Borland C klager hvis man ikke gør det:

D:\Program\NG>cat test.c
#include <stdio.h>

int main(void)
{
puts("Hello world\n");
}

D:\Program\NG>gcc -Wall test.c -o test.exe
test.c: In function `main':
test.c:6: warning: control reaches end of non-void function

D:\Program\NG>bcc32 test.c
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
test.c:
Warning W8070 test.c 6: Function should return a value in function main
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland


Jeg vil således anbefale alle at returnere noget explicit fra alle
funktioner der er sat til at returnere noget.

/b

---

Den Mon, 14 Apr 2003 21:07:23 +0200 skrev Bertel Brander:
>Jeg ønsker egentlig ikke at træde mere rundt i dette, og ja, det er
>veldefineret at undlade at retunere noget fra main, men om det er en
>god idé, er en anden sag, GCC og Borland C klager hvis man ikke gør det:
>
>D:\Program\NG>cat test.c
>#include <stdio.h>
>
>int main(void)
>{
> puts("Hello world\n");
>}
>
>D:\Program\NG>gcc -Wall test.c -o test.exe
>test.c: In function `main':
>test.c:6: warning: control reaches end of non-void function

Når du bruger -Wall så beder du explicit compileren om at advare dig
om alle de steder du *måske* har glemt en linie.

Det er altså ikke fordi det er en fejl, det er simpelthen fordi
compileren siger "hov, her returnerer du ikke noget. Hvis du vil
returnere andet end 0, så har du glemt en return".

Det giver også fejl på if(a=b), fordi du *måske* har glemt at skrive
==, eller måske mente du netop if(a=b), compileren kan ikke vide
det.

Mvh
Kent
--
Is windows userfriendly? Nah, more like optimized for idiots.

---

On Mon, 14 Apr 2003 21:07:23 +0200, Bertel Brander wrote:

> Jeg ønsker egentlig ikke at træde mere rundt i dette, og ja, det er
> veldefineret at undlade at retunere noget fra main, men om det er en
> god idé, er en anden sag, GCC og Borland C klager hvis man ikke gør det:

Siger jo måske mere om compilerne end om standarden, men derudover er jeg
ening i, at man lige så godt kan gøre det til en vane altid at returnere en
værdi.

/\/\\ads Orbesen Troest

---

Bertel Lund Hansen skrev:
> -Uncle- skrev:
>
>
>>Jeg er lidt ny ifaget, og mangler lidt hjælp. Jeg skal have konverteret 4
>>char til en long, jeg har lavet et lille testprg. ,men den kommer ikke ud
>>med det rigtige facit. Hvad gør jeg galt.
>
>
> Char rummer præcis 8 bit, og hvis du skifter den 8 pladser, giver
> det enten 0 eller 255.

Tillad mig at korigere:
char rummer MINDST 8 bit, men kan indeholde 8, 9, 19, 32, 64 bits eller
hvad den der laver kompileren synes. Der findes flere ANSI-C compilere
der bruger 32 bit char.

Hvis du skifter en 8 bit-char 8 pladser har du en int, da en int er
mindst 16 bit er der ingen trunkering.

/bertel

---

Den Sun, 13 Apr 2003 21:47:25 +0200 skrev Bertel Brander:
>Bertel Lund Hansen skrev:
>> -Uncle- skrev:
>>
>>
>>>Jeg er lidt ny ifaget, og mangler lidt hjælp. Jeg skal have konverteret 4
>>>char til en long, jeg har lavet et lille testprg. ,men den kommer ikke ud
>>>med det rigtige facit. Hvad gør jeg galt.
>>
>>
>> Char rummer præcis 8 bit, og hvis du skifter den 8 pladser, giver
>> det enten 0 eller 255.
>
>Tillad mig at korigere:
>char rummer MINDST 8 bit, men kan indeholde 8, 9, 19, 32, 64 bits eller
>hvad den der laver kompileren synes. Der findes flere ANSI-C compilere
>der bruger 32 bit char.
>
>Hvis du skifter en 8 bit-char 8 pladser har du en int, da en int er
>mindst 16 bit er der ingen trunkering.

Øhm, hvor i standarden står der at char er mindst 8 bit, og int er
mindst 16 bit?

Mig bekendt er eneste krav at
sizeof char<=sizeof short<=sizeof int<=sizeof long

Mvh
Kent
--
NT er brugervenligt - det er bare brugerne der ikke kan finde ud af det
- en NT-administrator

---

Kent Friis wrote:
> Øhm, hvor i standarden står der at char er mindst 8 bit, og int er
> mindst 16 bit?

Det kommer an på hvilken standard vi snakker om. I ISO/IEC 9899:1999
(C99) står det i afsnit 5.2.4.2.1.

Der ses også at short skal være mindst 8 bit, long mindst 32 bit, og
long long mindst 64 bit.

---

Byrial Jensen skrev:
>> Øhm, hvor i standarden står der at char er mindst 8 bit, og int er
>> mindst 16 bit?
>
>
> Det kommer an på hvilken standard vi snakker om. I ISO/IEC 9899:1999
> (C99) står det i afsnit 5.2.4.2.1.
>
> Der ses også at short skal være mindst 8 bit, long mindst 32 bit, og
> long long mindst 64 bit.
>
Hvis man nærlæser afsnit 5.2.4.2.1 kan man se:

"The values given below shall be replaced by constant expressions
suitable for use in #if preprocessing directives. Moreover, except
for CHAR_BIT and MB_LEN_MAX, the following shall be replaced by
expressions that have the same type as would an expression that is
an object of the corresponding type converted according to the integer
promotions. Their implementation-defined values shall be equal or
greater in magnitude (absolute value) to those shown, with the same
sign."

.....

"-- minimum value for an object of type short int
SHRT_MIN -32767 // -(2^15- 1)
-- maximum value for an object of type short int
SHRT_MAX +32767 // 2^15 - 1
-- maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 2^16 - 1"

Hvilket vil sige at en short er mindst 16 bit.

/b

---

> Øhm, hvor i standarden står der at char er mindst 8 bit, og int er
> mindst 16 bit?
>
> Mig bekendt er eneste krav at
> sizeof char<=sizeof short<=sizeof int<=sizeof long
>
> Mvh
> Kent


Der står i C standarden at en unsigned char mindst skal kunne have
værdierne fra 0 til og med 255, dette indebærer at en unsigned char
skal have mindst 8 bit.
For unsigned short og unsigned int er kravet 0 til og med 65535,
hvilket kræver 16 bit, for en unsigned long er kravet 0 til og med
4294967295, hvilket giver 32 bit. Tilsvarende gælder for de tilhørende
signed udgaver.

/b

---

On Sun, 13 Apr 2003 18:24:21 +0200, "-Uncle-" <oz7aev@tdcadsl.dk>
wrote:

>Hej NG.
>
>Jeg er lidt ny ifaget, og mangler lidt hjælp. Jeg skal have konverteret 4
>char til en long, jeg har lavet et lille testprg. ,men den kommer ikke ud
>med det rigtige facit. Hvad gør jeg galt.

> nr = (a+(b<<8)+(c<<16)+(d<<24));

Hej Jens

Kig lidt på det du egentlig beder compileren om

Du erklærer 4 char's, hvilke bliver signed, da du ikke anfører
unsigned. Deres værdiområde bliver da -128...+127 for compilerens
vekommende. Du gør da en lille "fejl" ved at tildele c = 234, da den
jo klart ligger uden for værdiområdet. Ved en char til unsigned long
typecast bliver det (234 = 0xEA) sign extended til noget du sikkert
ikke lige forventer, nemlig 0xFFFFFFEA, dette skifter du så 16 bit til
venstre, det er her problemet så opstår.

Definer blot dine char's som unsigned, så skulle den være i vinkel du


Rigtigt resultat: 2095726891
Forkert resultat: 2078949675

/Thomas

---

-Uncle- skrev:
> Hej NG.
>
> Jeg er lidt ny ifaget, og mangler lidt hjælp. Jeg skal have konverteret 4
> char til en long, jeg har lavet et lille testprg. ,men den kommer ikke ud
> med det rigtige facit. Hvad gør jeg galt.
>
> Mvh Jens
>
> #include <stdio.h>
> #include <conio.h>
> #include <string.h>
> #include <stdlib.h>
>
> char a=43;
> char b=65;
> char c=234;
> char d=124;
> unsigned long nr;
>
> void main(void)
> {
> nr = (a+(b<<8)+(c<<16)+(d<<24));
> printf("%lu",nr);
> getch();
> }
>
Jeg kan se flere mulige fejl her:

1: char er enten unsigned eller signed, det afhænger af kompileren
(og hvilke flag du giver kompileren), hvis du skal have dit testprogram
til at virke skal a, b, c, d være unsigned, så du er nødt til at skrive:
unsigned char a = 43;
etc.

2: Resultatet af a << n (når a er en unsigned char) er en unsigned int,
hvis en unsigned int er 16 bit og n er >= 8 er det udefineret hvad der
sker, så du er nød til at kaste til en unsigned long for at være sikker
på at der ikke kommer trunkering, f.eks:
((unsigned long )a) << n;

De næste fire er for pedanterne;

3: conio.h er ikke en standard headerfil, resultatet er udefineret.

4: main skal retunere en int, ellers er resultatet udefineret.

5: getch er ikke en standard funktion -> udefineret resultat.

6: main skal retunere 0, EXIT_SUCCESS eller EXIT_FAILURE, ellers
har du udefineret resultat.

/b

--
Bertel Brander, author of Wain, a free text editor for programmers:
http://home20.inet.tele.dk/midgaard/program.htm

---

"Bertel Brander" <bertel@post4.tele.dk> wrote:
> Jeg kan se flere mulige fejl her:
[...]
> De næste fire er for pedanterne;
>
> 3: conio.h er ikke en standard headerfil, resultatet er udefineret.

s/udefineret/implementationsspecifikt/

Ikke en fejl.

med pedantisk hilsen, Anders

---

"Bertel Brander" <bertel@post4.tele.dk> wrote


[8<8<8<]
> 4: main skal retunere en int, ellers er resultatet udefineret.

I en hosted environment er resultatet veldefineret - det oversætter ikke
(med mindre man har en fejlbehæftet implementering).
På en freestanding environment er resultatet og navnet på funktionen, der
kaldes under startup implementations defineret. Altså ikke udefineret og
ikke defineret af C eller C++ Standarden.
Se eventuelt §3.6.1 i C++ Standarden eller §5.1.2.1 i C Standarden for
yderligere detaljer.

[8<8<8<]
> 6: main skal retunere 0, EXIT_SUCCESS eller EXIT_FAILURE, ellers
> har du udefineret resultat.

Du tager fejl.
Hvis main ikke explicit returnerer noget, svarer det til at returnere 0.
Hvorfra har du den opfattelse ?
Se §3.6.1-5 og §18.3-8 i C++ Standarden eller §5.1.2.2.3 og §7.20.4.3-5 i
C99 Standarden.

Venlig hilsen

Mogens Hansen

---

Hej igen NG

Jeg takker for svarene, jeg kan kun sige at al begyndelse er svær, men da
jeg så Thomas's svar på mit indlæg, var jeg selv klar over hvad mit problem
var, jeg havde bare stiret mig blind.....hmm.

Mvh Jens

Ps. Det kan være jeg kommer med flere spørgsmål, da jeg arbejder på et
projekt som har en deadline om et par uger....

---

> Jeg er lidt ny ifaget, og mangler lidt hjælp. Jeg skal have konverteret 4
> char til en long, jeg har lavet et lille testprg. ,men den kommer ikke ud
> med det rigtige facit. Hvad gør jeg galt.

Sjovt.. jeg sad med samme "projekt" og problem i dag.

Men fik det dog løst efter lang tid faktisk.

#define LITTLE_SHORT_INDIAN(x,y) (unsigned short)x + ((unsigned short)(y) <<
8L)
#define LITTLE_LONG_INDIAN(a,b,c,d) ( (unsigned long)a + ( ((unsigned long)
b) << 8L) + ( ((unsigned long) c) << 16L) + (( (unsigned long) d) << 24L))

Disse 2 makroer er testet og virker .. dog sad jeg længe og bøvlede med
dem - de gav ikke rigtigt facit.

Problemet var, at min buffer fra filen var læst i et char array (allokeret
med malloc - men det er nu underordnet).

Det har åbenbart en fatal betydning for resultatet, for typen skal være af
"unsigned char" før det virker!

Det kunne sagtens være det, der var dit problem også.

Klaus.