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

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

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.

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.

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

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.

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.

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:  --

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

>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