Hollosi Information eXchange /HIX/
HIX CODER 189
Copyright (C) HIX
1998-08-13
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
1 Re: *** HIX CODER *** #188 (mind)  28 sor     (cikkei)
2 ReRe: void main() es egyeb allatfajtak (mind)  69 sor     (cikkei)
3 void main() es egyeb allatfajtak (mind)  14 sor     (cikkei)
4 Visual C++ 4.0 (mind)  4 sor     (cikkei)
5 HW =~SW, FPGA (mind)  28 sor     (cikkei)
6 Re: void main() es egyeb allatfajtak (mind)  92 sor     (cikkei)
7 igazatok van, a casting nem KORRUMPAL!!!! (mind)  12 sor     (cikkei)
8 Re: void main() es egyeb allatfajtak (mind)  33 sor     (cikkei)
9 RE: findfirst (mind)  12 sor     (cikkei)
10 Re: void main() es egyeb allatfajtak (mind)  67 sor     (cikkei)

+ - Re: *** HIX CODER *** #188 (mind) VÁLASZ  Feladó: (cikkei)

Hali!

>En szerintem a Benko-ek fele Programozzunk C nyelven cimu
>(megdobbentoen alacsony szinvonalu konyv) is boven meritett
>Herbert-tol, igy jokat derulhetunk a
>
>char c;
>c = getchar();
>
>tipusu konstrukciokon, bar lehet hogy inkabb sirni kellene. (Ha nem
>erted hogy ez miert teheti korrupta a memoriat ideje mar, hogy egy
>"igazi" C konyvet is elolvass...).

Haaat nemtom....
En elso ranezesre sem talaltam semmi kivetnivalot a dologban, de hat ugye
nem csak nekem lehet igazam, ezert megneztem mit fordit ebbol a fordito
assembly-re. Az eredmeny engem igazolt NEM lesz ettol korrupt a memoria. (Az
egesz vege MOV _C$[EBP],CL) Te valoszinuleg arra gondoltal, hogy a getchar
visszateresi erteke int, a c meg char. Nos ez a C-ben teljesen korrekt,
mivel ilyenkor a fordito beiktat egy automatikus tipuskonverziot, esetleg ha
az adott warning engedelyezett, kapsz egy "conversion from 'int' to 'char',
possible loss of data" warningot. A fenti megoldas csak akkor okoz
problemat, ha pld. egy while( c != EOF ) sort is beiktatsz, mert akkor az
elso 0xff karaktert is EOF-nak erzekeli a kodod.

P.S. Talan kevesebb "igazi" C konyvet kellene olvasnod? :>)

Compi
+ - ReRe: void main() es egyeb allatfajtak (mind) VÁLASZ  Feladó: (cikkei)

Hali!

>Az az allitasom hogy a:
>
>> char c;
>> c = getchar();
>
>alapvetoen hibas. Megvallom utana szandekosan kekeckedtem egy kicsit:
>
>>(Ha nem erted hogy ez miert teheti korrupta a memoriat ideje mar,
>> hogy egy "igazi" C konyvet is elolvass...).

>Sokan felbosszankodtak, hadd valaszoljak itt nehany pontra:
>
>>En elso ranezesre sem talaltam semmi kivetnivalot a dologban, de
>>hat ugye nem csak nekem lehet igazam, ezert megneztem mit fordit
>>ebbol a fordito assembly-re. Az eredmeny engem igazolt NEM lesz
>>ettol korrupt a memoria.
>
>Elso szabaly. Teljesen irrelevans mit fordit a forditod! Rossz kodbol
>is fordithat jot, jobol is rosszat.


Bocs, de ez unfair-volt. A valaszomnak csak azt a reszet idezted, ami
tulajdonkeppen nem valasz a problemara, es ami pedig az, azt kihagytad. En
csak azert neztem meg a forditott kodot, mert nem a "hateztisztahulye"
alapallasbol mentem neki a felvett problemanak, hanem elobb meg akartam
gyozodni rola, hogy tenyleg ugy van-e ahogyan en tudom.

Akkor most az erdemi valasz megegyszer, kisse maskent fogalmazva:

A C(++) alapvetoen tipusorientalt nyelv. Amennyiben egy A tipusu valtozoba B
tipusu erteket raksz ket eset lehetseges: A B tipusu erteket automatikusan A
tipusuva konvertalja az ertekadas elott, illetve amennyiben ezt nem tudja
(vagy nem akarja) elvegezni hibat jelez. _SEMMIKEPPEN_ sem tortenhet az,
hogy az A tipusu (es meretu) valtozo cimere B tipusu (es meretu) adat kerul.
Amennyiben ez megis megtortenik, az adott fordito NEM FELEL MEG az ANSI C
szabvanynak!!!!!

>#include <stdio.h>
>int
n(){ 
>  char c;
>  c = getchar();
>  while ( c != EOF) {
>    putchar(c);
>    c = getchar();
>  }
>  return 0;
>}
>
>Nos ez a progi esetleg jol lefordulhat es futhat a te gepeden, pl.
>nalam a Sun Ultra-n. Nacceru. Utana leforditom Silicon Graphics-on. 
>Vegtelen ciklusba kezd, kiir ketmilio ketpontos y-t majd egy bekes
>core-dump-pal elalszik. 

Na latod ilyenkor van ertelme belenezni a forditott kodba, mert 99% hogy hibas 
a f
ordito. Egy char tipusu valtozo kezdocimere egy esetben kerulhet int:
int    i;
char   c;
 ...
 *((int*)&c) = i;
amennyiben a fenti valtozodeklaraciok eseten a
c = i;
ertekadasnak az az eredmenye, hogy c kezdocimere sizeof(i) byte-ot pakol a
program, akkor a fordito _HIBAS!_

Compi
+ - void main() es egyeb allatfajtak (mind) VÁLASZ  Feladó: (cikkei)

Szia Szinbad!

> char c;
> c = getchar();
>
> tipusu konstrukciokon, bar lehet hogy inkabb sirni kellene. (Ha nem
> erted hogy ez miert teheti korrupta a memoriat ideje mar, hogy egy
> "igazi" C konyvet is elolvass...).

En nem ertem miert teheti korruptta a memoriat, tudsz mondani konkret
konyve(ke)t? (Magyarorszagon beszerezhetot!)

Koszonom:
Tibi.
+ - Visual C++ 4.0 (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok CODER-ek nemrég kezdtem a Visual C++ 4.0 tanulásába, de sajnos
semmiféle irodalmat sem találtam a programról, ha tudtok olyan könyveket,
vagy internethelyeket -Lehetoleg magyarul-ahonnan információt tudok a
témáról szerezni kérlek segítsetek.Elore is köszi.
+ - HW =~SW, FPGA (mind) VÁLASZ  Feladó: (cikkei)

Coderek:

Ezer bocs, hogy zavarom a csapatot ilyen kerdesekkel. Beutottem 
az ASIC-ot a US  alta vizslaba, 116,000 jott ki, atneztem parat, 
de egyik sem olyan jo mint ami a Coderektol privat e-mailen jott.
Ezert jobb egy posting a Coderba mint egy search a vizslaba. 
(ugy tunik, a coder visszaallt a "business as usual" allapotba, 
nem kell foglalkoznuk "underqualified-alkalmatlan" emberekkel itt) 

Coder szempontbol a HW=SW. Teljesen mindegy hol fut
a code amit a coder irt. A memoriaba vagy egy chipbe.
 . Code az code, ez fut egy CPU-ba meg ha a floppyrol
toltod be. Semmi kulonbseg.
Az adathordozon a kulonbseg, ami ASIC eseten egy chip.
Azt szeretnem megtudni valamelyik Codertol, hogy hogyan
zajlik egy ilyen ASIC gyarto  muvelet le a kalyhatol a kesz chipig.
A masik, mi az a FPGA. Az utobbi par evben kicsit tavol kerultem 
a HW kozeli dolgoktol, ezt is  jo lenne tudnom most. 
Kedves Marosinak: a kereses nem eleg,  egy jo  konzultansot keresek.  
Talan el kelne egy jo HW news group is, a bit-VOLT  bogaraszo
embereknek. Nulla Volt = a bit nulla, 5V = a bit EGY.
De mit csinalsz ha 2.5V  jon a vonalon meg egy csomo zaj. 
Laslo Chaki
President
ACD-GAMMA, Inc.
(949)360-4155
http://www.acdcon.com/career.htm
We bring good developers in US
+ - Re: void main() es egyeb allatfajtak (mind) VÁLASZ  Feladó: (cikkei)

Hello,

Az az allitasom hogy a:

> char c;
> c = getchar();

alapvetoen hibas. Megvallom utana szandekosan kekeckedtem egy kicsit:

>(Ha nem erted hogy ez miert teheti korrupta a memoriat ideje mar, 
> hogy egy "igazi" C konyvet is elolvass...).

Sokan felbosszankodtak, hadd valaszoljak itt nehany pontra:

>En elso ranezesre sem talaltam semmi kivetnivalot a dologban, de 
>hat ugye nem csak nekem lehet igazam, ezert megneztem mit fordit 
>ebbol a fordito assembly-re. Az eredmeny engem igazolt NEM lesz 
>ettol korrupt a memoria.

Elso szabaly. Teljesen irrelevans mit fordit a forditod! Rossz kodbol
is fordithat jot, jobol is rosszat.

>Ettol az lesz, hogy (mivel a char elojeles - ha at nincs allitva) 
>az EOF-ot mar akkor is eszreveszi a program, (mar ha egyaltalan
>teszteli a programozo ;) amikor veletlenul a ket pontos y

Vagy nem. Ismet, arra hogy mit hogyan vesz eszre a program forditas 
utan arra nem lehet szamitani. Senkinek semmi koze ahhoz hogy a EOF
hogyan van reprezentalva. Annyit kell tudni hogy integer szam kell
legyen. A char elojelessege is platform fuggo! Nem atallitas kerdese.
Sosem szabad arra epitkezni ami nem kovetelmeny. Egy Torveny van 
csupan: az ANSI Standard, s annak ki vetkez Memoriaja Kivagatik.

A lenyeg mashol van. Vegyuk ezt a peldaprogit:

/* a.c */
#include <stdio.h>
int main(){ 
  char c;
  c = getchar();
  while ( c != EOF) {
    putchar(c);
    c = getchar();
  }
  return 0;
}

futtasd: a.exe < a.c

Nos ez a progi esetleg jol lefordulhat es futhat a te gepeden, pl.
nalam a Sun Ultra-n. Nacceru. Utana leforditom Silicon Graphics-on. 
Vegtelen ciklusba kezd, kiir ketmilio ketpontos y-t majd egy bekes
core-dump-pal elalszik. 

Tudom hogy tudjatok:
A getchar() integer-t ad vissza, az EOF meg mondjuk lehet -1 vagy 
valami mas ami esetleg nem fer bele a c-be. A javitas trivialis: 
int c-t kell deklaralni. De, foleg ezen javitas egyszerusege 
mutatja hogy az illeto konyv szerzoi epp a lenyeget nem ertik a 
C nek. Azt hogy platform fuggetlen. Az nem C ami csak egy bizonyos 
gepen fordul le helyesen. Az bohocsag. Annal nagyobb mivel egy C-t
tanito konyvben van benne harom irta, ketto lektoralta, aki meg 
tanulja magara vessen.

Konnyu kezlegyintassel elintezni, de velemenyem szerint a programok 
legveszelyesebb hibai pont az ilyen egyszeru dolgokbol fakadnak.

Es egy jellemzo pelda: A vilag legdragabb komputer-bug-ja. Az 
Ariane 5 nehany evel ezelotti lezuhanasa. Nem a mernokok voltak 
hibasak, nem az iranyitotorony adott hibas utasitas es nem is a
termeszet jatszott gunyos jatekot. Pontosan egy olyan hiba volt
amilyent az elobb targyaltunk, de meg annal is nevetsegesebb:

long double d;
int i;
i = d;

Mivel az Ariane 4 konstrukciojabol fakadoan a d erteke 65536-nal 
nem lehetett nagyobb (most irrelevans hogy ez ponotsan mit mert) 
ugy dontottek hogy nem tesznek bele egy ellenorzo rutint. De a 
technika fejlodott de mire az Ariane 5 -ot megcsinaltak amely 
profibb volt mar senki sem emlekezett miert is nem ellenorzik
az illeto konverziot. Tulcsordulas, Operand Error,
es a rendszer ellszallt. 500 millio dollar kar. Meg valami,a 
program ADA-ban volt irva.

http://www.dcss.mcmaster.ca/~griffin/2me3/refcate/ariene5.htm
http://www.around.com/ariane.html

csak jot,

szin.
+ - igazatok van, a casting nem KORRUMPAL!!!! (mind) VÁLASZ  Feladó: (cikkei)

Ezer bocs,

Nagyon beleeltem magam a korrumpalasba. Erre nehanyan megkopogtattak a 
fejemet es latak, hogy kong. 

A helytelen casting nem szabad korrumpaljon hiszen nem ostoba ADA-val
van dolgunk mint a Ariane-soknak hanem szepen fejlett C-vel. A jelzett
konstrukcio ugyan szarvashiba marad de persze egeszen mas okok miatt.

megegyszer bocs mindenkitol es koszi a kijavitasokat.

szindbad.
+ - Re: void main() es egyeb allatfajtak (mind) VÁLASZ  Feladó: (cikkei)

On 12 Aug 98 at 10:39,  > wrote:

> char c;
> c = getchar();
> 
> tipusu konstrukciokon, bar lehet hogy inkabb sirni kellene. (Ha nem
> erted hogy ez miert teheti korrupta a memoriat ideje mar, hogy egy
> "igazi" C konyvet is elolvass...).

Biztos az a baj, hogy egyetlen C konyvet sem olvastam eddig :)) 
nemhogy az igazit, de nem ertem, miert tehetei _ez_ korruptta a 
memoriat?

Ettol az lesz, hogy (mivel a char elojeles - ha at nincs allitva) az 
EOF-ot mar akkor is eszreveszi a program, (mar ha egyaltalan teszteli 
a programozo ;) amikor veletlenul a ket pontos y (˙ - remelem, atmegy 
ez az ekezet a HIX-en, ISO-8859-1..2 255-os kod) kodot olvassa a 
standard inputrol. Ha olyan nincs a szovegben, akkor minden ugyanugy 
megy.

Felreteve a trefat, termeszetesen egyetertek veled, hogy aki ilyet
ir, az nem ismeri a getchar()-t. Hasonlokeppen aki void-os main-t ir,
azt is leszoktatta a jomodorrol a Microsoft :)) azzal, hogy mar a DOS
sem, de fokeppen a Windows, nem tamogatja teljes mellszelesseggel a
sok kis programbol epitkezo programozasi technikat, a Unix erosseget. 

[Tegnap, bevallom ferfiasan - bar nem void-os volt a main, amit
a Hanoi-ban irtam - en is beleestem abba a hibaba, hogy nem 
return-oltem 0-at a main vegen.]

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --
+ - RE: findfirst (mind) VÁLASZ  Feladó: (cikkei)

Hi all!

Gondoltam hatha tanul belole valaki...
Rajottem, miert nem ment Pascal alol az unc neves eleres a halon. Ugy,
hogy mas alol se ment volna. Ugy tunik a w98 alatti kliensem nem tud
ilyet, mert NT alatt tokeletesen mukodik. Tehat jol gondoltam, hogy ez
nyelvfuggetlen dolog, mert a pascal is meg a tobbi is a dost hivja, azon
meg ul a kliens.
Csiszar L-nek meg kosz a helpet.

udv
 Arp
+ - Re: void main() es egyeb allatfajtak (mind) VÁLASZ  Feladó: (cikkei)

>char c;
>c = getchar();

>tipusu konstrukciokon, bar lehet hogy inkabb sirni kellene. (Ha nem
>erted hogy ez miert teheti korrupta a memoriat ideje mar, hogy egy
>"igazi" C konyvet is elolvass...).


Hat akkor most mar tenyleg kell keresnem egy igazi C konyvet, mert nem
igazan ertem ez hogy 'korrumpalja' a memoriat...

az automatikus cast szerintem 'mindent' +old, lasd a fordito altal keszitett
asm kodot

int c; eset
 .
 .
 .
 call far ptr __fgetc
 add sp,4
 mov word ptr [bp-2],ax


char c; eset
 .
 .
 .
 call far ptr __fgetc
 add sp,4
 mov word ptr [bp-1],al


latszik hogy az __fgetc (mivel a getchar 1 makro) mindket esetben AX ben ad
vissza 'int' erteket ahogy kell, es a fordito a +felelo meretu valtozoba
teszi a helyere


megjegyzesek:
    - igaz en csak egy forditoval probaltam, es csak DOS LARGE platformra
    - ha a fordito ebbol rossz kodot general az mas teszta, szerintem ebben
az esetben az
      automatikus cast az ansi C-ben kovetelmeny
    - ismet mas kerdes hogy mas fv. eseteben adat veszte's is lehet ez a
cast

reszlet a BC5 DOS help-bol

************************************
Description

Gets character from stdin.
getchar is a macro that returns the next character on the named input stream
stdin. It is defined to be getc(stdin).

Note: Do not use this function for Win32s or Win32 GUI applications.

Return Value

On success, getchar returns the character read, after converting it to an
int without sign extension.
On end-of-file or error, it returns EOF.
************************************

Bocs ha hosszu lett

udv
    Hofi

AGYKONTROLL ALLAT AUTO AZSIA BUDAPEST CODER DOSZ FELVIDEK FILM FILOZOFIA FORUM GURU HANG HIPHOP HIRDETES HIRMONDO HIXDVD HUDOM HUNGARY JATEK KEP KONYHA KONYV KORNYESZ KUKKER KULTURA LINUX MAGELLAN MAHAL MOBIL MOKA MOZAIK NARANCS NARANCS1 NY NYELV OTTHON OTTHONKA PARA RANDI REJTVENY SCM SPORT SZABAD SZALON TANC TIPP TUDOMANY UK UTAZAS UTLEVEL VITA WEBMESTER WINDOWS