🚀 go-pugleaf

Qrczak wrote:
> 
> main (int argc, char *argv[])
> {
>     ...
>     Czy teraz wolno zmieniać zawartość argv[][] (nie zwiększając
> bieżącej długości), czy też parametry wywołania są zmiennymi tylko do
> odczytu?

Podejrzewan, ze zalezy to od konkretnej implementacji - konkretniej
modulku c0??.obj ktory jest linkowany z programem. W modulku tym jest
'entry point' do programu, z niego jest wolany main. W BC5 nie ma z tym
problemu, gdzie indziej raczej tez nie powinno.

Pawel

Qrczak wrote:

> main (int argc, char *argv[])
> {
>     ...
>     Czy teraz wolno zmieniać zawartość argv[][] (nie zwiększajšc
> bieżšcej długości), czy też parametry wywołania sš zmiennymi tylko do
> odczytu?
>

Tak

Qrczak wrote:
> 
> main (int argc, char *argv[])
> {
>     ...
>     Czy teraz wolno zmieniać zawartość argv[][] (nie zwiększając
> bieżącej długości), czy też parametry wywołania są zmiennymi tylko do
> odczytu?

Nie wiem, czy o to chodzi w pytaniu, ale main() jest zwykla funkcja,
wiec argv zachowuje sie dokladnie tak, jak argumenty innych funkcji.

	pozdrawiam

-- 
gracjan ziółek
system administrator

Sebastian Tylko wrote:

> Qrczak wrote:
>
> > main (int argc, char *argv[])
> > {
> >     ...
> >     Czy teraz wolno zmieniać zawartość argv[][] (nie zwiększajšc
> > bieżšcej długości), czy też parametry wywołania sš zmiennymi tylko do
> > odczytu?
> >
>
> Tak

Tak (tzn. wolno tam zapisywać )

Gracjan =?iso-8859-2?Q?Zi=F3=B3ek?= wrote:

Co do  samego meritum  watku: zgodnie ze standardem mozna
modyfikowac zarowno argc, jak i argv (wskazniki), a takze
zawartosci  tych   wskaznikow.  Rozsadek   nakazuje,   by
zmieniac tylko znaki lezace w obrebie przekazanych ciagow
znakow, tak jak to tu sugerowano, ale standard o tym  nie
mowi.


> Nie wiem, czy o to chodzi w pytaniu, ale main() jest zwykla funkcja,
> wiec argv zachowuje sie dokladnie tak, jak argumenty innych funkcji.

Otoz funkcja main nie jest taka jak inne. Czym sie rozni?
Podam trzy sprawy, ktore nasuwaja sie natychmiast:

1. Od  funkcji main zaczyna sie dzialanie programu (pomi-
jam przypadki  niestandardowych funkcji startujacych, np.
w BORLAND  C, chociaz  i one  sa swoistym  argumentem  za
wyjatkowoscia funkcji main). Jest to tez jedyna funkcja w
programie,   ktorej    istnienie   jest    z    definicji
obligatoryjne.

2. main  jest jedyna funkcja standardowa w C (chociaz nie
biblioteczna  :-)),   ktora  mozna   wywolac   calkowicie
poprawnie  zarowno   bez  argumentow,   jak  i   z  dwoma
argumentami (nie  mowimy tu,  rzecz jasna, o funkcjach ze
zmienna liczba argumentow).

3. Po zakonczeniu funkcji main otoczenie wywoluje funkcje
exit,  z  wartoscia  zwrocona  z  main  jako  argumentem.
Realizuje tez  inne  operacje,  jak  np.  zamyka  otwarte
zbiory i  usuwa zbiory  tymczasowe  utworzone  za  pomoca
funkcji tmpfile.  Zatem zakonczenie dzialania main jest -
mowiac  obrazowo  -  bardziej  brzemienne  w  skutki  niz
zakonczenie dzialania normalnej funkcji.

Sa  jeszcze   inne  sprawy,   zwiazane   z   inicjowaniem
argumentow   statycznych    i    otwieraniem    strumieni
standardowych (sa one zalezne od implementacji jezyka C i
mozna dyskutowac,  na ile  uprawnione jest wiazanie ich z
wywolaniem main). Nie jest zatem main zwykla funkcja, jak
kazda inna  (w koncu, badz co badz, nazywa sie main czyli
"glowna"  :-)).  I  jeszcze  jedno:  w  kilku  postingach
zauwazylem swojego czasu nastepujaca definicje main

void main(void)
...

To blad.  Funkcja main  powinna byc  zawsze typu int. Tak
stanowi standard.  Roznica  ma  znaczenie  dla  sekwencji
wolajacej i konczacej funkcje main. Dzialanie programu, w
ktorym main  ma typ void, jest - formalnie rzecz biorac -
niezdefiniowane.

  Pozdrawiam

  Marek Kotowski

Gracjan =?iso-8859-2?Q?Zi=F3=B3ek?= wrote:
> 
> Jasne, jasne... Wszyscy to wiedza i pytanie nie tego dotyczylo. W sensie
> argumentow, zwracania wartosci itp. main() jest taka sama funkcja, jak
> inne. I o to mi chodzilo.

  Pozwole sobie nie zgodzic sie. 
  Otoz jesli funkcja main jest rozna od innych, to wlasnie
"w sensie argumentow i zwracania wartosci". Cialo funkcji
main moze byc takie, jak cialo kazdej innej funkcji.

  Marek Kotowski

On Wed, 21 Jan 1998 12:13:24 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>Gracjan =?iso-8859-2?Q?Zi=F3=B3ek?= wrote:
>> 
>> Jasne, jasne... Wszyscy to wiedza i pytanie nie tego dotyczylo. W sensie
>> argumentow, zwracania wartosci itp. main() jest taka sama funkcja, jak
>> inne. I o to mi chodzilo.
>
>  Pozwole sobie nie zgodzic sie. 
>  Otoz jesli funkcja main jest rozna od innych, to wlasnie
>"w sensie argumentow i zwracania wartosci". 

 Niby dlaczego ? Czyzby nie dalo sie jej przekazaywac argumentow jak
kazdej innej funkcji i czy nie zwraca ona tak samo wartosci ?
Wszystkie sprawy zwiazane z pamiecia, srodowiskiem, etc. sa _poza_
funkcja main() i maja zwiazek z kompilatorem a nie jezykiem.

milosz danielewski

Marek Kotowski wrote:
> 
> Gracjan =?iso-8859-2?Q?Zi=F3=B3ek?= wrote:
> 
> Co do  samego meritum  watku: zgodnie ze standardem mozna
> modyfikowac zarowno argc, jak i argv (wskazniki), a takze
> zawartosci  tych   wskaznikow.  Rozsadek   nakazuje,   by
> zmieniac tylko znaki lezace w obrebie przekazanych ciagow
> znakow, tak jak to tu sugerowano, ale standard o tym  nie
> mowi.

I o to wlasnie chodzilo. Ze mozna.

> > Nie wiem, czy o to chodzi w pytaniu, ale main() jest zwykla funkcja,
> > wiec argv zachowuje sie dokladnie tak, jak argumenty innych funkcji.
> 
> Otoz funkcja main nie jest taka jak inne. Czym sie rozni?
> Podam trzy sprawy, ktore nasuwaja sie natychmiast:
> 1. Od  funkcji main zaczyna sie dzialanie programu [...]
> 2. [...]
> 3. Po zakonczeniu funkcji main otoczenie wywoluje funkcje
> exit,  z  wartoscia  zwrocona  z  main  jako  argumentem [...]
[...]

Jasne, jasne... Wszyscy to wiedza i pytanie nie tego dotyczylo. W sensie
argumentow, zwracania wartosci itp. main() jest taka sama funkcja, jak
inne. I o to mi chodzilo.

	pozdrawiam :)
	
-- 
gracjan ziółek
system administrator

Marek Kotowski wrote:
> 
> Gracjan =?iso-8859-2?Q?Zi=F3=B3ek?= wrote:
> >
> > Jasne, jasne... Wszyscy to wiedza i pytanie nie tego dotyczylo. W sensie
> > argumentow, zwracania wartosci itp. main() jest taka sama funkcja, jak
> > inne. I o to mi chodzilo.
> 
>   Pozwole sobie nie zgodzic sie.
>   Otoz jesli funkcja main jest rozna od innych, to wlasnie
> "w sensie argumentow i zwracania wartosci". Cialo funkcji
> main moze byc takie, jak cialo kazdej innej funkcji.

Niewazne. Wiem o co chodzilo Qrczakowi, on wie (tak mysle...) o co mnie,
wiec sprawa rozwiazana.

	pozdrawiam :)

-- 
gracjan ziółek
system administrator

milosz danielewski wrote:
> 
> On Wed, 21 Jan 1998 12:13:24 +0100, Marek Kotowski <mkot@imm.org.pl>
> wrote:
> >  Pozwole sobie nie zgodzic sie.
> >  Otoz jesli funkcja main jest rozna od innych, to wlasnie
> >"w sensie argumentow i zwracania wartosci".
> 
>  Niby dlaczego ? Czyzby nie dalo sie jej przekazaywac argumentow jak
> kazdej innej funkcji i czy nie zwraca ona tak samo wartosci ?

  Rozumiem, ze postuluje Pan wywolanie

  main(cos1, cos2);   :-)

  Jesli mowimy tylko o C, a nie o innych jezykach czy srodowiskach,
z ktorych wywoluje sie program w C, to to moze oznaczac tylko wywolanie
rekurencyjne main. W standardzie nie ma oficjalnie czegokolwiek
na ten temat. Widzialem kilka programow zglaszanych na konkurs
IOCCC, w ktorych wywolywano rekurencyjnie main. Ale to inna sprawa.

  Co do sprawy glownej. Main jest funkcja specjalna. Nie wiadomo,
kto i jak wywoluje main. Owszem, programiscie dane jest wszystko, 
co sie dzieje miedzy wywolaniem main i jej koncem. Wie, jak wywolac
funkcje, i jak zwracac wartosci. Ale nie wie, np. komu zwraca
wartosc, konczac main. To moga byc inne programy, srodowiska, etc.
Standard nieprzypadkiem duzo o tym mowi, by bylo jasne, jak rzecz
wyglada, czy powinna wygladac.
  Podam przyklad: programowalem kiedys w kompilatorze COBOL-u,
ktory pozwalal - poprzez asembler wbudowany - wywolywac programy
w C. Argumenty dla main przekazywalo sie w ES:BX. Nie bylo to zatem
przekazywanie argumentow "jak kazdej innej funkcji".
  I jeszcze slowo co do wywolania main: jesli Pan z gory zalozy, 
ze wywolanie tej funkcji jest takie same jak kazdej innej w
programie w jezyku C, to tym samym zalozy Pan implicite, ze
zostala ona wywolana przez inny kod w jezyku C, z wlasna funkcja
main, co jest oczywiscie sprzecznoscia sama w sobie.
Owszem, autorzy standardu starali sie, by funkcja dzialala mozliwie
podobnie, jak inne funkcje w C. Ale oczywiscie sa wyrazne
roznice (opisalem podstawowe z nich w innym poscie, chociaz,
zdaje sie, niewiele to niektorych dyskutantow obchodzi).

  Pozdrawiam

  Marek Kotowski

PS. Moj przyjaciel podpowiada mi dobre porownanie programu 
    w C do duszy czlowieka. Nie wiemy, co bylo z nasza dusza
    przed naszym urodzeniem, i co bedzie z nia po naszym
    zgonie. :-) Niestety, nie ma tu zadowalajacego standardu,
    ktory by cos o tym mowil.:-)

Marek Kotowski wrote:
> 
> PS. Moj przyjaciel podpowiada mi dobre porownanie programu
>     w C do duszy czlowieka. Nie wiemy, co bylo z nasza dusza
>     przed naszym urodzeniem, i co bedzie z nia po naszym
>     zgonie. :-) Niestety, nie ma tu zadowalajacego standardu,
>     ktory by cos o tym mowil.:-)

No tak, a proba zmiany zawartosci "argv, argc"  to tak jak seans
spirytystyczny. Moze sie udac, moze tez nie wyjsc, ale i tak to jedno
wielkie oszustwo. ;)))
						pozdrawiam
							Mirek

On Wed, 21 Jan 1998, Marek Kotowski wrote:

> Co do  samego meritum  watku: zgodnie ze standardem mozna
> modyfikowac zarowno argc, jak i argv (wskazniki), a takze
> zawartosci  tych   wskaznikow.
[...]

Dziękuję wszystkim za tę informację.

> Otoz funkcja main nie jest taka jak inne.

IMHO formalnie jest taką samą funkcją niż każda inna. Kompilator
kompiluje ją tak samo jak wszystkie inne! A co się dzieje "na zewnątrz"
jej i jak jest wywoływana, to już nie ma znaczenia.

> 1. Od  funkcji main zaczyna sie dzialanie programu
[...]

To nie przeszkadza.

> 2. main  jest jedyna funkcja standardowa w C (chociaz nie
> biblioteczna  :-)),   ktora  mozna   wywolac   calkowicie
> poprawnie  zarowno   bez  argumentow,   jak  i   z  dwoma
> argumentami (nie  mowimy tu,  rzecz jasna, o funkcjach ze
> zmienna liczba argumentow).

Nie "wywołać", bo jawnie się jej nie wywołuje. Dlatego może mieć różną
liczbę argumentów. To ma być wyjątkowe? Przecież funkcja o nazwie
moja_funkcja też może mieć dowolną liczbę argumentów!

> 3. Po zakonczeniu funkcji main otoczenie wywoluje funkcje
> exit,  z  wartoscia  zwrocona  z  main  jako  argumentem.
[...]

To nie jest cecha samej funkcji main, tylko tego, co ją wywołuje.

> Sa  jeszcze   inne  sprawy,   zwiazane   z   inicjowaniem
> argumentow   statycznych    i    otwieraniem    strumieni
> standardowych (sa one zalezne od implementacji jezyka C i
> mozna dyskutowac,  na ile  uprawnione jest wiazanie ich z
> wywolaniem main).

Nie widzę powodu, żeby to było wiązane z wywołaniem funkcji main.

> I  jeszcze  jedno:  w  kilku  postingach
> zauwazylem swojego czasu nastepujaca definicje main
> 
> void main(void)
> ...
> 
> To blad.
[...]

Zgadza się.

-- 
                                 QRCZAK
    __("<              Marcin Kowalczyk
    \__/              qrczak@knm.org.pl
     ^^      http://qrczak.home.ml.org/

On Thu, 22 Jan 1998 10:34:44 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>milosz danielewski wrote:
>> 
>> On Wed, 21 Jan 1998 12:13:24 +0100, Marek Kotowski <mkot@imm.org.pl>
>> wrote:
>> >  Pozwole sobie nie zgodzic sie.
>> >  Otoz jesli funkcja main jest rozna od innych, to wlasnie
>> >"w sensie argumentow i zwracania wartosci".
>> 
>>  Niby dlaczego ? Czyzby nie dalo sie jej przekazaywac argumentow jak
>> kazdej innej funkcji i czy nie zwraca ona tak samo wartosci ?
>
>  Rozumiem, ze postuluje Pan wywolanie
>
>  main(cos1, cos2);   :-)
>
>  Co do sprawy glownej. Main jest funkcja specjalna. Nie wiadomo,
>kto i jak wywoluje main. 

 Zgadzam sie, nie wiadomo kto main wywoluje, jednak ten fakt nie
implikuje "innosci" tej funkcji. Co do tego jak jest ona wywolywana,
to jestem przekonany, ze tak jak kazda inna i nie moze byc inaczej (
tzn. moze ale byloby to bez sensu ).

>Owszem, programiscie dane jest wszystko, 
>co sie dzieje miedzy wywolaniem main i jej koncem. Wie, jak wywolac
>funkcje, i jak zwracac wartosci. Ale nie wie, np. komu zwraca
>wartosc, konczac main. To moga byc inne programy, srodowiska, etc.
>Standard nieprzypadkiem duzo o tym mowi, by bylo jasne, jak rzecz
>wyglada, czy powinna wygladac.
>  Podam przyklad: programowalem kiedys w kompilatorze COBOL-u,
>ktory pozwalal - poprzez asembler wbudowany - wywolywac programy
>w C. Argumenty dla main przekazywalo sie w ES:BX. Nie bylo to zatem
>przekazywanie argumentow "jak kazdej innej funkcji".

 Owszem, tylko ze nie przekazywales tych argumentow _bezposrednio_
funkcji main. Twoj przyklad tylko potwierdza moja teze o tym, ze main
to zwykla funkcja - gdyby panowala w tym wzgledzie dowolnosc, nie
moglbys wywolywac programow skompilowanych innymi narzedziami.

>  I jeszcze slowo co do wywolania main: jesli Pan z gory zalozy, 
>ze wywolanie tej funkcji jest takie same jak kazdej innej w
>programie w jezyku C, to tym samym zalozy Pan implicite, ze
>zostala ona wywolana przez inny kod w jezyku C, z wlasna funkcja
>main, co jest oczywiscie sprzecznoscia sama w sobie.

To pozorna sprzecznosc - oczywiscie tak wlasnie jest !

>PS. Moj przyjaciel podpowiada mi dobre porownanie programu 
>    w C do duszy czlowieka. Nie wiemy, co bylo z nasza dusza
>    przed naszym urodzeniem, i co bedzie z nia po naszym
>    zgonie. :-) Niestety, nie ma tu zadowalajacego standardu,
>    ktory by cos o tym mowil.:-)

 Kto nie wie, ten nie wie :)

milosz danielewski

milosz danielewski wrote:
[...]
> 
> >  I jeszcze slowo co do wywolania main: jesli Pan z gory zalozy,
> >ze wywolanie tej funkcji jest takie same jak kazdej innej w
> >programie w jezyku C, to tym samym zalozy Pan implicite, ze
> >zostala ona wywolana przez inny kod w jezyku C, z wlasna funkcja
> >main, co jest oczywiscie sprzecznoscia sama w sobie.
> 
> To pozorna sprzecznosc - oczywiscie tak wlasnie jest !

Rozumiem zatem, ze skoro "tak wlasnie jest" to rzecz wyglada tak

/* JAKIS PROGRAM */
int main(int argc, char **argv)
{
  ... 
  main(1, JakisPtr);  /* To main wywoluje funkcje main innego programu 
                         podana nizej */
}

/* INNY PROGRAM */
int main(int argc, char **argv)
{
  ...
}

  Bardzo osobliwe. :-)

> >PS. Moj przyjaciel podpowiada mi dobre porownanie programu
> >    w C do duszy czlowieka. Nie wiemy, co bylo z nasza dusza
> >    przed naszym urodzeniem, i co bedzie z nia po naszym
> >    zgonie. :-) Niestety, nie ma tu zadowalajacego standardu,
> >    ktory by cos o tym mowil.:-)
> 
>  Kto nie wie, ten nie wie :)

  To jest najwazniejsza uwaga w calym watku, albo w calej
grupie, albo nawet we wszystkich grupach dyskusyjnych. :-)
Rozumiem, ze w przeciwienstwie do mnie Pan wie. Prosze
nie byc egoista i natychmiast sie z nami podzielic swoja
wiedza.

  Pozdrawiam i czekam niecierpliwie na oswiecenie w sprawie
duszy, mojej i nie tylko

  Marek Kotowski

Qrczak <qrczak@knm.org.pl> napisal
> On Wed, 21 Jan 1998, Marek Kotowski wrote:
> 
> > Co do  samego meritum  watku: zgodnie ze standardem mozna
> > modyfikowac zarowno argc, jak i argv (wskazniki), a takze
> > zawartosci  tych   wskaznikow.
> [...]
> 
> Dziękuję wszystkim za tę informację.

Ja np. prawie zawsze stosuje konstrukcje

int main (int argc, char * argv [])
{
argc--;
...
}

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

Qrczak wrote:
> 
> > 2. main  jest jedyna funkcja standardowa w C (chociaz nie
> > biblioteczna  :-)),   ktora  mozna   wywolac   calkowicie
> > poprawnie  zarowno   bez  argumentow,   jak  i   z  dwoma
> > argumentami (nie  mowimy tu,  rzecz jasna, o funkcjach ze
> > zmienna liczba argumentow).
> 
> Nie "wywo³aæ", bo jawnie siê jej nie wywo³uje. Dlatego mo¿e mieæ ró¿n±
> liczbê argumentów. To ma byæ wyj±tkowe? Przecie¿ funkcja o nazwie
> moja_funkcja te¿ mo¿e mieæ dowoln± liczbê argumentów!

  Nieprawda. W jezyku C kazda funkcja ma dokladnie okreslona liczbe
argumentow. Po to m.in. wprowadzono prototypy, by zapewnic
przestrzeganie w modulach poprawnosci wywolywan funkcji,
w tym liczby argumentow. Jesli Pan wywola funkcje np. strlen
z trzema parametrami dostanie Pan - czy tez powinien Pan dostac -
informacje o bledzie (zakladajac, ze do modulu wlaczony jest 
odpowiedni plik definicyjny). Powtorze: pomijam funkcje ze zmienna 
liczba argumentow (to inna sprawa).
  
> > Sa  jeszcze   inne  sprawy,   zwiazane   z   inicjowaniem
> > argumentow   statycznych    i    otwieraniem    strumieni
> > standardowych (sa one zalezne od implementacji jezyka C i
> > mozna dyskutowac,  na ile  uprawnione jest wiazanie ich z
> > wywolaniem main).
> 
> Nie widzê powodu, ¿eby to by³o wi±zane z wywo³aniem funkcji main.

  Tu zgoda. Mozna ma ten temat dyskutowac i widziec powod lub nie.
Byc moze wszystko polega na podejsciu: czy mowimy o cechach 
funkcji main, czy otoczenia, ktore ja wywoluje. 
  Na koniec dodam jeszcze jeden argument: w standardzie (mam
ksiazke Plaugera & Brodiego) napisano wprost, ze np. argc mozna
modyfikowac - zalozenie pozornie zbedne. W koncu co mogloby
byc zlego w zmodyfikowaniu liczby przekazywanej przez wartosc?
Uznano jednak za wazne to podkreslic, jako ze argc przekazywane
jest z zewnatrz, przez byt :-), o ktorym teoretycznie nic nie
wiadomo.


  Pozdrawiam

  Marek Kotowski

Marek Kotowski <mkot@imm.org.pl> napisa³(a) w artykule <34C8723E.5485@imm.org.pl>...

[ciach]
>   Nieprawda. W jezyku C kazda funkcja ma dokladnie okreslona liczbe
> argumentow. 
[ciach]

A funkcja printf ?
 
>   Pozdrawiam
> 
>   Marek Kotowski
> 

I ja równie¿


-----------------------------------------
Jaroslaw Kucypera
mailto:jark@insert.com.pl
-----------------------------------------

Jarek Kucypera wrote:

> >   Nieprawda. W jezyku C kazda funkcja ma dokladnie okreslona liczbe
> > argumentow.
> [ciach]
> 
> A funkcja printf ?

  Funkcja printf jest funkcja ze zmienna liczba argumentow,
a ja dokladnie napisalem, ze pomijam tu te sprawe. 

  Marek Kotowski

On Fri, 23 Jan 1998, Marek Kotowski wrote:

> > Nie "wywołać", bo jawnie się jej nie wywołuje. Dlatego może mieć różną
> > liczbę argumentów. To ma być wyjątkowe? Przecież funkcja o nazwie
> > moja_funkcja też może mieć dowolną liczbę argumentów!
> 
>   Nieprawda. W jezyku C kazda funkcja ma dokladnie okreslona liczbe
> argumentow. Po to m.in. wprowadzono prototypy, by zapewnic
> przestrzeganie w modulach poprawnosci wywolywan funkcji,
> w tym liczby argumentow.

Ale funkcja main nie ma wcześniej prototypu! _Jedyną_ różnicą jest to,
co się dzieje "na zewnątrz" funkcji main. Oprócz tego, że jest
wywoływana automatycznie w określonej sytuacji, jest taka jak wszystkie.
Mogę zdefiniować:

moja_funkcja()
{ ... }

a w innym programie mogę tak:

moja_funkcja(int n)
{ ... }

To jest oczywiste, prawda?

I _dokładnie_ to samo jest w przypadku funkcji main. Też w jednym
programie może mieć inną liczbę argumentów niż w innym.

Oczywiście jeśli zdefiniuję funkcję main z argumentem typu double, to
program źle zadziała. Ale przynajmniej teoretycznie powinien się
skompilować, chyba że jakiś kompilator będzie miał dodane sztuczne
ograniczenia zabezpieczające przed tym (gcc łyka i
char *main(double x)).

Po prostu jest tak: Mamy zbiór dowolnych funkcji. Kompilujemy każdą w
taki sam sposób. Na koniec dołączamy kod ze standardowego modułu (już
nie napisany w C), który jakoś tam wywołuje funkcję main i interpretuje 
odpowiednio jej wynik.

> Na koniec dodam jeszcze jeden argument: w standardzie (mam
> ksiazke Plaugera & Brodiego) napisano wprost, ze np. argc mozna
> modyfikowac - zalozenie pozornie zbedne. W koncu co mogloby
> byc zlego w zmodyfikowaniu liczby przekazywanej przez wartosc?
> Uznano jednak za wazne to podkreslic, jako ze argc przekazywane
> jest z zewnatrz, przez byt :-), o ktorym teoretycznie nic nie
> wiadomo.

IMHO nie pozornie, a faktycznie zbędne. Tak _musiało_ być. Zostało to
powiedziane, żeby rozwiać ewentualne wątpliwości tych, którzy myślą, że
main jest czymś szczególnym :-)

-- 
                                 QRCZAK
    __("<              Marcin Kowalczyk
    \__/              qrczak@knm.org.pl
     ^^      http://qrczak.home.ml.org/

Dnia Fri, 23 Jan 1998 11:34:38 +0100 Marek Kotowski <mkot@imm.org.pl> napisal tak:

>  Nieprawda. W jezyku C kazda funkcja ma dokladnie okreslona liczbe
>argumentow.

Zaraz, zaraz. A taka funkcja ile ma argumentow:

int taka_jedna();

???

VANITAS VANITATUM ET OMNIA VANITAS

Mechanik

On Fri, 23 Jan 1998 11:09:03 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>milosz danielewski wrote:
>[...]
>> 
>> >  I jeszcze slowo co do wywolania main: jesli Pan z gory zalozy,
>> >ze wywolanie tej funkcji jest takie same jak kazdej innej w
>> >programie w jezyku C, to tym samym zalozy Pan implicite, ze
>> >zostala ona wywolana przez inny kod w jezyku C, z wlasna funkcja
>> >main, co jest oczywiscie sprzecznoscia sama w sobie.
>> 
>> To pozorna sprzecznosc - oczywiscie tak wlasnie jest !
>
>Rozumiem zatem, ze skoro "tak wlasnie jest" to rzecz wyglada tak
>
>/* JAKIS PROGRAM */
>int main(int argc, char **argv)
>{
>  ... 
>  main(1, JakisPtr);  /* To main wywoluje funkcje main innego programu 
>                         podana nizej */
>}
>
>/* INNY PROGRAM */
>int main(int argc, char **argv)
>{
>  ...
>}
>
>  Bardzo osobliwe. :-)

 Osobliwe, czy nie, tak wlasnie jest zrobione. Tylko pierwsze
narzedzie musialo byc napisane w innym jezyku. Pozwole sobie zacytowac
Qrczaka z dalszej czesci tego watku:
 "Po prostu jest tak: Mamy zbiór dowolnych funkcji. Kompilujemy każdą
w taki sam sposób. Na koniec dołączamy kod ze standardowego modułu
(już nie napisany w C), który jakoś tam wywołuje funkcję main i
interpretuje odpowiednio jej wynik. "
 Z mala uwaga - ten kod ze standardowego modulu tez jest w C.


>
>> >PS. Moj przyjaciel podpowiada mi dobre porownanie programu
>> >    w C do duszy czlowieka. Nie wiemy, co bylo z nasza dusza
>> >    przed naszym urodzeniem, i co bedzie z nia po naszym
>> >    zgonie. :-) Niestety, nie ma tu zadowalajacego standardu,
>> >    ktory by cos o tym mowil.:-)
>> 
>>  Kto nie wie, ten nie wie :)
>
>  To jest najwazniejsza uwaga w calym watku, albo w calej
>grupie, albo nawet we wszystkich grupach dyskusyjnych. :-)
>Rozumiem, ze w przeciwienstwie do mnie Pan wie. Prosze
>nie byc egoista i natychmiast sie z nami podzielic swoja
>wiedza.

 Nie jestem egoista, ale tak jak nie mieszam sledzi z dzemem, tak nie
wdaje sie w zadne swiatopogladowo-filozoficzne dyskusje na grupie
"lang" !

milosz danielewski

milosz danielewski wrote:
>  Nie jestem egoista, ale tak jak nie mieszam sledzi z dzemem, tak nie
> wdaje sie w zadne swiatopogladowo-filozoficzne dyskusje na grupie
> "lang" !

  Czy to znaczy, ze po to, aby sie dowiedziec, jak to jest
z tymi duszami, musze sie przeniesc na inna grupe?
Prosze powiedziec, gdzie i kiedy moze Pan udzielic 
mi stosownych wyjasnien? :-)
  A wlasciwie dlaczego nie na moj prywatny adres?
Bede zobowiazany. :-)


  Pozdrawiam

  Marek Kotowski

Mechanik wrote:
> Zaraz, zaraz. A taka funkcja ile ma argumentow:
> 
> int taka_jedna();
> 

Taka funkcja wedlug K&R nie ma argumentow. Wedlug zas
standardu ANSI C jej argumenty sa nieokreslone. Nie
jest to zatem pelny prototyp funkcji. Jesli funkcja
ma nie miec argumentow, powinno to byc zaznaczone
explicite slowem void:

int taka_jedna(void);

  Pozdrawiam

  Marek Kotowski

Qrczak wrote:
> Ale funkcja main nie ma wcze¶niej prototypu! 

  Ma domyslny. Nie ma go w plikach definicyjnych, ale
zna go kompilator. Ale mniejsza.

[...]

  Przeczytalem Pana wypowiedz i mysle sobie, ze zgodzilismy
sie juz, ze mozna na rzecz patrzec roznie.
  Jedna sprawa wymaga podkreslenia.  Zrozumialem Panska
poprzednia wypowiedz tak, ze Pan sugeruje, iz jedna funkcja moze byc
wywolywana z  rozna liczba  argumentow w  obrebie jednego
programu czy nawet jednego modulu. Z tego Panskiego postu
wynika, ze myslal Pan o roznych programach. Tym samym moj
zarzut "Nieaprawda.itd".  byl niesluszny. Co przyznaje  i
przepraszam. 

  Pozdrawiam

  Marek Kotowski

Dnia Fri, 23 Jan 1998 22:32:34 GMT mdaniel@priv.onet.pl (milosz danielewski) napisal tak:

> Tylko pierwsze
>narzedzie musialo byc napisane w innym jezyku. Pozwole sobie zacytowac
>Qrczaka z dalszej czesci tego watku:

> "Po prostu jest tak: Mamy zbiór dowolnych funkcji. Kompilujemy każdą
>w taki sam sposób. Na koniec dołączamy kod ze standardowego modułu
>(już nie napisany w C), który jakoś tam wywołuje funkcję main i
>interpretuje odpowiednio jej wynik. "

> Z mala uwaga - ten kod ze standardowego modulu tez jest w C.

U mnie kod zrodlowy tego modulu siedzi w pliku c:\bc45\lib\startup\c0.asm i wyglada na
program w asemblerze. :-)


VANITAS VANITATUM ET OMNIA VANITAS

Mechanik

Sebastian Tylko <seba@bobo.ds5.agh.edu.pl> wrote:
: Qrczak wrote:

:> main (int argc, char *argv[])
:> {
:>     ...
:>     Czy teraz wolno zmieniać zawartość argv[][] (nie zwiększajšc
:> bieżšcej długości), czy też parametry wywołania sš zmiennymi tylko do
:> odczytu?
:>

: Tak

Alez kolega jest stuprocentowo pewny. Ja nie robilbym tego na jego miejscu.

Wyjasnie wiec dokladnie na czym sprawa polega.

Gdyby main'a zadeklarowac w ten sposob:

int main( int argc, const char ** const argv );

To zmienic niczego w argv NIE WOLNO.
Poniewaz jednak programisci nie stosuja takich naglowkow, wiec... wolno.

Wszystko tez zalezy od tego, JAK chcesz zmieniac argv. Bo argv jest po prostu
zmienna typu 'char**' w zwiazku z czym zluzy jednie do tego, zeby do niej
zostal wpisany odpowiedni wskaznik (przekazywany do funkcji). Tak tez nic
nie stoi na przeszkodzie, by po prostu na nowo przydzielic mu tablice
dwuwymiarowa itd.

Wystrzegalbym sie jednak dokonywania modyfikacji w tablicy drugiego poziomu,
a juz ABSOLUTNIE w tablicy pierwszego poziomu! Intuicyjnie do tego podchodzac,
tablica ta moze (i pewnie jest) tworzona w ten sposob:

argv = new char* [argc];
nazwa par1 par2 par3
|    ^|   ^|   ^|   ^
|    0|   0|   0|   0
|     |    |    |
[0]   |    |    |
[1]---'    |    |
[2]--------'    |
[3]-------------'

Prosze zwrocic uwage: w miejsce spacji wstawiane sa zera, a nastepnie wskazniki
w tablicy drugiego poziomu sa wypelniane adresami poczatkow tych napisow.
Jezeli jest to tak robione, to w zasadzie nie stoi nic na przeszkodzie, zeby
przypisac tym elementom inne adresy, ale proba uzycia np.
strcat( argv[2], "cos" );
moze byc BARDZO przykra w skutkach (z SIGSEGV wlacznie).

-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

Marek Kotowski <mkot@imm.org.pl> wrote:
: Mechanik wrote:
:> Zaraz, zaraz. A taka funkcja ile ma argumentow:
:> 
:> int taka_jedna();
:> 

: Taka funkcja wedlug K&R nie ma argumentow. Wedlug zas
: standardu ANSI C jej argumenty sa nieokreslone. Nie
: jest to zatem pelny prototyp funkcji. Jesli funkcja
: ma nie miec argumentow, powinno to byc zaznaczone
: explicite slowem void:

: int taka_jedna(void);

Moze niespecjalnie szczesliwie zacytowalem jedna z tych wypowiedzi toczacych
sie wokol funkcji main. Aby nie bylo watpliwosci:

1. Kazda funkcja ma scisle okreslona liczbe argumentow (powyzsza funkcja ma
0 argumentow).
2. Funkcja main moze miec 3 prototypy:
int main( );
int main( int argc, char** argv );
int main( int argc, char** argv, char** envp );

Takie prototypy sie stosuje. Niemniej jednak oczywiscie funkcja ta moze miec
absolutnie dowolny prorotyp! Naglowek tej funkcji tylko po prostu wskazuje,
jakich argumentow taka funkcja moze oczekiwac na stosie (wzglednie w rejestrach
procesora). Moze te argumenty uwzglednic albo je olac. Nie ma tez zadnych
przeciwwskazan, zeby zadeklarowac inne parametry! Tyle tylko, ze moga byc to
bezsensowne wartosci. Musimy jednie pamietac, ze pierwszy parametr jest liczba
calkowita o dlugosci sizeof (int), a dwa nastepne dwustopniowym wskaznikiem
na typ o dlugosci sizeof (char).
No i jeszcze jedno. Wartosc, jaka po zakonczeniu funkcji main znajdzie sie na
stosie (lub w rejestrze, w ktorym oczekuje sie wartosci zwracanej) jest
przekazywana srodowiskowi programu (ktory logicznie wywoluje funkcje main).
Tu tez trzeba uwazac, dlatego, ze jezeli zadeklarujemy zwracany typ funkcji
main jako void, to do srodowiska programu zostanie zawsze przekazana wartosc
zwrocona przez ostatnio wywolywana funkcje (chyba, ze uzyjemy exit)! Pod DOS-em
i UNIX-em nie musi to miec znaczenia, jezeli program nie musi zwracac wartosci
srodowiskowi programu. Jeden z moich kumpli nacial sie jednak w ten sposob na
amidze (program przebiegl poprawnie, ale po wyjsciu zyztem zglosil blad).

Mam nadzieje, ze rozwialo to wszystkie watpliwosci na temat funkcji main.
Pozdrawiam,

-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

Michal Malecki wrote:
> 2. Funkcja main moze miec 3 prototypy:
> int main( );
> int main( int argc, char** argv );
> int main( int argc, char** argv, char** envp );
> 

  Poprawka: zgodne ze standardem sa tylko dwa prototypy:

 int main(void);   /* void, a nie pusta lista argumentow */
 int main(int argc, char** argv);

Zmienne otoczenia, owszem, w wiekszosci implementacji C moga byc
przekazywane jako trzeci argument main, ale w standardzie nie sa
opisane. Natomiast przewidziano dla ich pobierania standardowa
funkcje biblioteczna o prototypie:

char *getenv(const char *name);

  Pozdrawiam

  Marek Kotowski

On 26 Jan 1998, Michal Malecki wrote:

> Wystrzegalbym sie jednak dokonywania modyfikacji w tablicy drugiego
> poziomu, a juz ABSOLUTNIE w tablicy pierwszego poziomu!

Mówiłem tylko o zmianach nie zwiększających długości tych łańcuchów!

A konkretnie, chcę zamienić np. \n na znak o kodzie 10 itd.
Ponieważ większość napisów się w ogóle nie zmieni, a pozostałe się
najwyżej skrócą, to szkoda by było wszystko kopiować.

-- 
                                 QRCZAK
    __("<              Marcin Kowalczyk
    \__/              qrczak@knm.org.pl
     ^^      http://qrczak.home.ml.org/

Marek Kotowski <mkot@imm.org.pl> wrote:
: Michal Malecki wrote:
:> 2. Funkcja main moze miec 3 prototypy:
:> int main( );
:> int main( int argc, char** argv );
:> int main( int argc, char** argv, char** envp );
:> 

:   Poprawka: zgodne ze standardem sa tylko dwa prototypy:

:  int main(void);   /* void, a nie pusta lista argumentow */
:  int main(int argc, char** argv);

: Zmienne otoczenia, owszem, w wiekszosci implementacji C moga byc
: przekazywane jako trzeci argument main, ale w standardzie nie sa
: opisane. 

No coz, musze kolege poprawic.
Aktualnie w standardzie jest ustalone, ze wskaznik na zmienne srodowiskowe
jest trzecim parametrem funkcji main.
Drugi sposob, to zmienna globalna, zwana environ (ale nie mam pewnosci, czy
zostalo to ujete w standardzie).

: Natomiast przewidziano dla ich pobierania standardowa
: funkcje biblioteczna o prototypie:
: char *getenv(const char *name);
No i to jest trzeci sposob.

Stanowczo pietnuje wytykanie mi pustych nawiasow!
W standardzie - jak na razie - nie ma roznicy pomiedzy () i (void) jako
listy parametrow funkcji. Jest to tylko dla odpowiedniego oznaczenia pustej
listy. Byc moze w standardzie kiedys pojawi sie propozycja, ze funkcja z
lista "()" jest funkcja o nieokreslonej liczbie parametrow i mozna ja wywolywac
w dowolny sposob. Na razie jednak standard nic takiego nie mowi i funkcje
o nie wpisanych parametrach wywoluje sie wylacznie bez parametrow.

Takich regulek mozna przytoczyc kilka. Jak ktos chce to niech sie ich trzyma,
obowiazku nie ma. Sa to np.:

W zasadzie nalezy:     Ale mozna tez:
STD:                   ALT:
void* t = NULL;        void* t = 0;
if ( t != NULL )       if ( t )
if ( arg[0] == '\0' )  if ( *arg )

Ja sie osobiscie stosuje do tej drugiej notacji i wcale nie uwazam tego za
zly styl programowania.

Pozdrawiam,

-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

Michal Malecki wrote:
> : Zmienne otoczenia, owszem, w wiekszosci implementacji C moga byc
> : przekazywane jako trzeci argument main, ale w standardzie nie sa
> : opisane.
> 
> No coz, musze kolege poprawic.
> Aktualnie w standardzie jest ustalone, ze wskaznik na zmienne srodowiskowe
> jest trzecim parametrem funkcji main.

  W standardzie ANSI C (1988) tego nie ma. Prosze mi podac
symbol i date poprawki do standardu, w ktorej to ujeto.

> Drugi sposob, to zmienna globalna, zwana environ (ale nie mam pewnosci, czy
> zostalo to ujete w standardzie).

  Nie. Ale jest w standardzie POSIX. I zazwyczaj jest obslugiwana
przez wiekszosc kompilatorow.

> Stanowczo pietnuje wytykanie mi pustych nawiasow!
> W standardzie - jak na razie - nie ma roznicy pomiedzy () i (void) jako
> listy parametrow funkcji. 

  Jest.

  Niech Pan napisze prototyp i wywolanie:

int Func();

...
  Func();

  W wiekszosci kompilatorow (ja pracuje z BC) dostanie Pan 
ostrzezenie, ze wywoluje Pan funkcje bez prototypu (oczywiscie
jesli zadne ostrzezenia nie beda maskowane).

> Jest to tylko dla odpowiedniego oznaczenia pustej
> listy. Byc moze w standardzie kiedys pojawi sie propozycja, ze funkcja z
> lista "()" jest funkcja o nieokreslonej liczbie parametrow i mozna ja wywolywac
> w dowolny sposob. Na razie jednak standard nic takiego nie mowi i funkcje
> o nie wpisanych parametrach wywoluje sie wylacznie bez parametrow.

  Patrz, wyzej.

> 
> Takich regulek mozna przytoczyc kilka. Jak ktos chce to niech sie ich trzyma,
> obowiazku nie ma. Sa to np.:
> 
> W zasadzie nalezy:     Ale mozna tez:
> STD:                   ALT:
> void* t = NULL;        void* t = 0;
> if ( t != NULL )       if ( t )
> if ( arg[0] == '\0' )  if ( *arg )

  Rozumiem, ze wedlug Pana obydwie postacie zapisu
w ostatniej linijce sa tez rownowazne. :-)
Ale w koncu moze sa. Tyle juz rzeczy osobliwych
przeczytalem w tej grupie. :-)   

  Pozdrawiam

  Marek Kotowski

On Wed, 21 Jan 1998, Marek Kotowski wrote:

> "glowna"  :-)).  I  jeszcze  jedno:  w  kilku  postingach
> zauwazylem swojego czasu nastepujaca definicje main
> 
> void main(void)
> ...
> 
> To blad.  Funkcja main  powinna byc  zawsze typu int. Tak
> stanowi standard.  Roznica  ma  znaczenie  dla  sekwencji
> wolajacej i konczacej funkcje main. Dzialanie programu, w
> ktorym main  ma typ void, jest - formalnie rzecz biorac -
> niezdefiniowane.

Na wiekszosci maszyn zwracanie argumentu funkcji jest realizowane
przez - zazwyczaj - rejestry. Nie ma to __zadnego__ wplywu na 
sekwencje wolajaca, maja natomiast argumenty wejsciowe - stos.
void main(void) jest stosowane w bardzo wielu programach i ma na 
celu podkreslenie ze sie nie zwraca zadnych wartosci.

> 
>   Pozdrawiam
> 
>   Marek Kotowski
> 
> 

pozdrawiam 
Codematic

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

On Fri, 23 Jan 1998, Marek Kotowski wrote:

> > >PS. Moj przyjaciel podpowiada mi dobre porownanie programu
> > >    w C do duszy czlowieka. Nie wiemy, co bylo z nasza dusza
> > >    przed naszym urodzeniem, i co bedzie z nia po naszym
> > >    zgonie. :-) Niestety, nie ma tu zadowalajacego standardu,
> > >    ktory by cos o tym mowil.:-)
> > 
> >  Kto nie wie, ten nie wie :)
> 
>   To jest najwazniejsza uwaga w calym watku, albo w calej
> grupie, albo nawet we wszystkich grupach dyskusyjnych. :-)
> Rozumiem, ze w przeciwienstwie do mnie Pan wie. Prosze
> nie byc egoista i natychmiast sie z nami podzielic swoja
> wiedza.

Ja przed smiercia bylem arabskim sultanem. Po smierci bede
zwiewnym duchem i latal po cmentarzach, bo limit reinkarnacji 
mi sie skonczyl.

Ja to wiem.

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

On Fri, 23 Jan 1998, Marek Kotowski wrote:

>   Nieprawda. W jezyku C kazda funkcja ma dokladnie okreslona liczbe
> argumentow. Po to m.in. wprowadzono prototypy, by zapewnic

a a() ? Ile ona ma argumentow ? Zero czy nieokreslone ?
Slyszalem ze standard to druga odpowiedz.

Prawde mowiac to mi sie juz kompletnie pochrzanilo co jest zgodne
ze standardem a co nie. I tak bede robil po swojemu :)
Przyznam ze najbardziej mnie zaskoczyly te 32KB w standardzie.
Przeciez to chyba najprzyjemniejsza cecha systemow z wymiana pamieci.
pisze a = malloc(400000l), readfromfile(a). Po co sie wysilac. Niech
Unix stronicuje.

> 
>   Pozdrawiam
> 
>   Marek Kotowski
> 
> 

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Maciej MOCHOL <mmochol@elka.pw.edu.pl> napisal
> On Fri, 23 Jan 1998, Marek Kotowski wrote:
> 
> >   Nieprawda. W jezyku C kazda funkcja ma dokladnie okreslona liczbe
> > argumentow. Po to m.in. wprowadzono prototypy, by zapewnic
> 
> a a() ? Ile ona ma argumentow ? Zero czy nieokreslone ?
> Slyszalem ze standard to druga odpowiedz.
> Prawde mowiac to mi sie juz kompletnie pochrzanilo co jest zgodne
> ze standardem a co nie. I tak bede robil po swojemu :)

Tez juz dostalem kociokwiku...
Dotychczas bylem przekonany ze 
                                                  C                   C++
0 argumentow:                        a (void)           a (void)  lub a ()
dowolna ilosc argumentow:      a ()                 a (...)

Jak jest faktycznie, pomocy !

> Przyznam ze najbardziej mnie zaskoczyly te 32KB w standardzie.

Ja tez zdebialem.. Toby oznaczalo ze jednak standard wspiera
architekture 16 bitowa... Chyba kilka latek za pozno..
Z drugiej strony widzialem w jednym miejscu w kodzie rodem z 
Suna patch zamieniajacy 32767 na 60000... 
Czyzby standard sie juz to jednak zmienil na 64KB ?

-- 
Pozdrawiam                                         Adam Karpierz   
mailto:karpierz@intertele.pl
http://www.intertele.pl/users/karpierz 

On Wed, 28 Jan 1998, Maciej MOCHOL wrote:

> Na wiekszosci maszyn zwracanie argumentu funkcji jest realizowane
> przez - zazwyczaj - rejestry. Nie ma to __zadnego__ wplywu na
> sekwencje wolajaca, maja natomiast argumenty wejsciowe - stos. void
> main(void) jest stosowane w bardzo wielu programach i ma na celu
> podkreslenie ze sie nie zwraca zadnych wartosci.

Ale zwykle wtedy zwróci jako kod wyjścia przypadkową wartość.
Nie należy pisać void main(), mimo że się nie zawiesi.

-- 
                                 QRCZAK
    __("<              Marcin Kowalczyk
    \__/              qrczak@knm.org.pl
     ^^      http://qrczak.home.ml.org/

Maciej MOCHOL wrote:
> 
> Ja przed smiercia bylem arabskim sultanem. Po smierci bede
> zwiewnym duchem i latal po cmentarzach, bo limit reinkarnacji
> mi sie skonczyl.
> 
> Ja to wiem.

  Wierze Panu. Bo co mi pozostaje? Moj umysl nie jest
w stanie pojac tego, co Pan napisal, ze przed smiercia
byl Pan sultanem (zatem Pan umarl), a po smierci bedzie
Pan duchem (zatem Pan nie umarl).
  Przyznaje: to nie sa problema dla umyslu programisty.
Zaiste, to nie do tej grupy. :-)

  Pozdrawiam 

  Marek Kotowski

Marek Kotowski <mkot@imm.org.pl> wrote:
: Michal Malecki wrote:
:> : Zmienne otoczenia, owszem, w wiekszosci implementacji C moga byc
:> : przekazywane jako trzeci argument main, ale w standardzie nie sa
:> : opisane.
:> 
:> No coz, musze kolege poprawic.
:> Aktualnie w standardzie jest ustalone, ze wskaznik na zmienne srodowiskowe
:> jest trzecim parametrem funkcji main.

:   W standardzie ANSI C (1988) tego nie ma. Prosze mi podac
: symbol i date poprawki do standardu, w ktorej to ujeto.

Nie ma ? Coz, dziwne. Moze sie i pomylilem. Wydawalo mi sie, ze widzialem
to jako standartowe ANSI C. Coz, jezeli tak w istocie nie jest, to przepraszam.

Takich danych (jak rok wydania standardu) nie posiadam, gdyz nie jestem 
kolekcjonerem informacji, ani historykiem, tylko programista. Totez to nie
moja dzialka.

:> Stanowczo pietnuje wytykanie mi pustych nawiasow!
:> W standardzie - jak na razie - nie ma roznicy pomiedzy () i (void) jako
:> listy parametrow funkcji. 

:   Jest.

:   Niech Pan napisze prototyp i wywolanie:

: int Func();

: ...
:   Func();

:   W wiekszosci kompilatorow (ja pracuje z BC) dostanie Pan 
: ostrzezenie, ze wywoluje Pan funkcje bez prototypu (oczywiscie
: jesli zadne ostrzezenia nie beda maskowane).

Az sprawdze!

Oto krociutki programik, kompilowany przy pomocy BC 3.1:

int funkcja();

int main()
{
        return funkcja();
}

int funkcja()
{
        return 0;
}

Nie otrzymalem najmniejszego ostrzezenia, ani komunikatu o bledzie!
Prosze mi wiec przyslac jakis program wraz z logiem kompilacji. Moze wtedy
uwierze w te panskie brednie.


:> Jest to tylko dla odpowiedniego oznaczenia pustej
:> listy. Byc moze w standardzie kiedys pojawi sie propozycja, ze funkcja z
:> lista "()" jest funkcja o nieokreslonej liczbie parametrow i mozna ja wywolywac
:> w dowolny sposob. Na razie jednak standard nic takiego nie mowi i funkcje
:> o nie wpisanych parametrach wywoluje sie wylacznie bez parametrow.

:   Patrz, wyzej.
Patrze i nic nie widze. W dalszym ciagu popieram to, co wczesniej napisalem.

:> 
:> Takich regulek mozna przytoczyc kilka. Jak ktos chce to niech sie ich trzyma,
:> obowiazku nie ma. Sa to np.:
:> 
:> W zasadzie nalezy:     Ale mozna tez:
:> STD:                   ALT:
:> void* t = NULL;        void* t = 0;
:> if ( t != NULL )       if ( t )
:> if ( arg[0] == '\0' )  if ( *arg )
               ^^              ^^^^

Niestety popelnilem blad. Zdarza sie. Oczywiscie, powinno byc !=, a nie
==. Ewentualnie !*arg zamiast *arg.

Zauwazylem, ze bardzo lubi pan teoretyzowac na temat tego jezyka. No coz.
Ja nie jestem tak "bogaty w kompilatory". Uzywalem tylko dwoch, jak na razie:
Borland C++ 3.1, oraz GNU C++ (nie pamietam, ktora wersja, w kazdym razie jedna
z najnowszych). Zawsze uzywam tego jezyka w taki sposob, jak to tutaj opisalem.
I jakos gcc nie stwarzal mi zadnych problemow.

Moze wiec zamiast teoretyzowac, przytoczy pan czasem choc jakis konkretny
przyklad ? Ja rozumiem, ze GCC moze miec swoje udogodnienia. Mnie tylko
chodzi (o odglos paszcza) o inne standartowe kompilatory, zwykle dostarczane
razem z systemem. Jezeli one cos takiego wytykaja - nie kloce sie. Dopoki
jednak operuje sie pustoslowiem do mnie niestety zadne argumenty nie trafiaja.

Pozdrawiam (ktorys tam juz raz z kolei), 


-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

Michal Malecki wrote:
> Oto krociutki programik, kompilowany przy pomocy BC 3.1:
> 
> int funkcja();
> 
> int main()
> {
>         return funkcja();
> }
> 
> int funkcja()
> {
>         return 0;
> }
> 
> Nie otrzymalem najmniejszego ostrzezenia, ani komunikatu o bledzie!
> Prosze mi wiec przyslac jakis program wraz z logiem kompilacji. Moze wtedy
> uwierze w te panskie brednie.

  Krotko:
  Zadalem sobie trud i skompilowalem ten program pod BC 3.1.
Daje ostrzezenie "Call to function "funkcja" with no prototype".
W czym rzecz? Otoz najpewniej ma Pan zamaskowane ostrzezenia.
Prosze wybrac z glownego ekran:

Options - Comopiler - Messages - Display.

  Sa tam trzy opcje: All, Selected, None.

  Tylko przy wyborze "None" nie bedzie komunikatu, bo tez i
jest to zazadanie, by nie bylo komunikatow. Przy "All" bedzie 
Pan mial komunikat. Przy "Selected" tylko wtedy, jak Pan zazada
wyswietlania komunikatu o braku prototypu funkcja (opcja 
"Less frequent errors"). 

  I tyle. 

  Uzyl Pan slowa "brednie". Moglbym tu sie wyzlosliwic,
ze brak kompetencji zastepuje Pan inwektywami. Moglbym napisac
pare innych rzeczy. Ale po tych kilku Pana wystapieniach w
grupie zaczynam watpic, czy w ogole warto z Panem dyskutowac.


  Marek Kotowski

Marek Kotowski <mkot@imm.org.pl> wrote:
:   Zadalem sobie trud i skompilowalem ten program pod BC 3.1.
: Daje ostrzezenie "Call to function "funkcja" with no prototype".
: W czym rzecz? Otoz najpewniej ma Pan zamaskowane ostrzezenia.
: Prosze wybrac z glownego ekran:
itd.
Wiem, ze tam sie cos wylacza, bo juz to "wylaczalem" pare razy. Prawdopodobnie
ma pan absolutna racje (nie sprawdzalem, jaka byla konfiguracja kompilatora,
jak to odpalalem, byc moze ktos (administrator :-) sobie to wylaczyl. I stad
cale nieporozumienie. Niemniej jednak sprawdze to jeszcze dzisiaj.

Mimo wszystko jednak po pierwsze sadze, ze i tak ma pan racje, a po drugie
wcale mnie to nie zdziwi. Maly przyklad:

if ( i = do_costam() )

GCC i BC zwroca uwage, ze w if uzyto operatora przypisania (byc moze mialby
to byc operator porownania). Natomiast w takim wypadku:

if ( (i = do_costam()) )

Tylko BC zwroci wyzej wymieniona uwage.

Zeby bylo jasniej, w tym pierwszym wypadku, to gcc dokladnie napisze cos w tym
stylu, ze "ambiguous expressions need parentheses".
Swiadczy to o tym po prostu, ze BC 3.1 ma zwyczaj generowania ostrzezen calkiem
bez sensu niekiedy. I wcale sie nie dziwie, dlaczego zostaja wylaczane.

:   Uzyl Pan slowa "brednie". Moglbym tu sie wyzlosliwic,
: ze brak kompetencji zastepuje Pan inwektywami. Moglbym napisac
: pare innych rzeczy. Ale po tych kilku Pana wystapieniach w
: grupie zaczynam watpic, czy w ogole warto z Panem dyskutowac.
Tak. Nie. Nie wiem. Ja osobiscie na brak kompetencji nie narzekam.
I nie zamierzam sie na pewno trzymac jakichs smiesznych regulek, ktore
honoruja najwyzej teoretycy jezyka. Bo gdybym mial to robic, to raczej
pozostalbym na etapie turbo-pascala. Przeciez mozliwosci ma podobne.
Skoro jednak dostapilem lepszego jezyka, to nie dlatego, ze uzywanie go
swiadczy o mnie czy cos w tym stylu. Tylko ja na prawde lubie ten jezyk.
I - m. in. dzieki mojej awersji do turbo-pascala - polubilem ten jezyk
od pierwszej przegladanej w ksiegarni ksiazki.

A tak troche na marginesie: Co mnie obchodzi, ze standard ANSI C czegos nie
okresla i "nie wiadomo jak to pojdzie na jakim kompilatorze". Juz nie
pierwszy raz powtarzam, ze jezeli pisze program, to od razu wiem, na jaki
kompilator i jaki system. Co mnie obchodzi, ze na inny system ten program
trzeba bedzie przerabiac ? A ile trwalo przeniesienie Linuxa na sparka ?


-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

Karpierz <karpierz@inter.intertele.pl> wrote:
: Maciej MOCHOL <mmochol@elka.pw.edu.pl> napisal
:> Prawde mowiac to mi sie juz kompletnie pochrzanilo co jest zgodne
:> ze standardem a co nie. I tak bede robil po swojemu :)

: Tez juz dostalem kociokwiku...
: Dotychczas bylem przekonany ze 
:                                                   C                   C++
: 0 argumentow:                        a (void)           a (void)  lub a ()
: dowolna ilosc argumentow:      a ()                 a (...)

: Jak jest faktycznie, pomocy !

No alescie mi namieszali! Jasna cholera! Az sprawdze jak to sie ma w gcc.

No wiec - nie wiem, jak sie to ma do standardu - sprawa ma sie tak:
Dla C:
Funkcja bez podanej listy parametrow W ZAPOWIEDZI moze byc wywolywana
i deklarowana Z DOWOLNYMI PARAMETRAMI. Wynika to zapewne z tego, ze niegdys
w zapowiedziach ("traditional" czy cos takiego) nie wpisywalo sie parametrow.
Dla C jest bez roznicy, wystarczy, zeby byla zapowiedz. Dopiero jak sie wpisze
konkretna liste parametrow (albo void albo parametry) to wtedy kompilator
moze sie "przypieprzac" do parametrow. Jezeli jednak zadeklarujemy funkcje
z bez listy parametrow, to jezeli nawet w realizacji bedziemy miec
funkcja( const char* t ), a wywolamy funkcja( 2.56 ) to kompilator nawet nie
miauknie. Oczywiscie za skutki musimy winic samych siebie...

Funkcja o zmiennej liscie parametrow w C moze wygladac jak a(). Ale - jak
mowie - w C tak moze wygladac kazda funkcja. Przykladowo printf ma taka
deklaracje:

int printf( const char*, ... );

Jedna wazna cecha funkcje o zmiennej liscie parametrow w C jest to, ze
MUSI wystapic przynajmniej jeden jawny parametr.

Musze wiec niestety przyznac racje, ze funkcja, ktora nie przyjmuje parametrow,
powinna miec w deklaracji void. Na swoja obrone moge powiedziec jedynie, ze
mnie akurat chodzilo o C++. Ja po prostu - o ile sytuacja mnie nie zmusi, jak w
przypadku muda - nie pisze juz nigdy niczego w C. Stad cale nieporozumienie.
Dla C++ wyglada sytuacja w ten sposob:

Funkcja podana w sposobie "a()" jest identyczna z "a( void )". Nie ma
mozliwosci podania dowolnej liczby parametrow. Jest to jedna z najwazniejszych
niezgodnosci pomiedzy C i C++. W C++ kazda funkcja przed wywolaniem musi byc
albo w pelni zdefiniowana, albo chociaz zapowiedziana. Niezapowiedzenie funkcji
w C++ jest bledem. Wynika to z jednej z mozliwosci funkcji w C++ - przecia-
zania. Poniewaz moga byc dwie funkcje o tej samej nazwie, kompilator musi je
rozrozniac.

Jezeli chodzi o zmienna liste parametrow, to w C++ akurat nie musi byc podana
jawnie lista parametrow. Oczywiscie zaleca sie stosowanie makr z stdarg.h,
( a przynajmniej uzywania makra __size ). Niemniej jednak - przykladowo -
jezeli mamy 32-bitowy int i wiemy, ze przekazuje sie jedynie zmienne typu
int lub wskaznikowego, mozemy obslugiwac to w ten sposob:

void funk( ... )
{
    int* args = ...;
    
    for ( int i = 0; NIEKONIEC; i++ )
        costam( args[i] );
}

Jezeli akurat zdarzy sie nam obslugiwac inne typy, mozemy dokonywac roznych
rzutowan. Jezeli jednak funkcja ma przyjmowac parametry tylko jednego typu,
ewentualnie typy nie szersze, niz int, to mozemy przystac na taka obsluge.
Jezeli np. funkcja ma przyjmowac parametry typu double (obowizaujacy typ
stalych zmiennoprzecinkowych), to deklarujemy sobie tablice:
double* args = ...;
Trzeba tylko pamietac, ze kompilator nie sprawdzi nam poprawnosci wywolania!
Gdyby chciec w ten sposob zadeklarowac funkcje do liczenia - przykladowo -
sredniej arytmetycznej, to musielibysmy wywolywac to tak:

EX( 2.0, 4.0, 6.0, 12.0, 8.0, 0.0, 0.3, -1 );

Na tym koniec dywagacji na temat vararg w C++.

No wiec coz. Jezeli piszemy w C, to jak sie ma funkcje o pustej liscie
parametrow, nalezy pisac void. Inaczej kompilator nie stwierdzi nam
ewentualnego bledu o zlej postaci wywolania funkcji.

Coz moglbym jeszcze dodac... Okazuje sie, ze co i raz dowiaduje sie czegos
nowego o C... jednak skonczyly sie juz czasy, gdy te informacje mialy rowniez
znaczenie dla C++.

:> Przyznam ze najbardziej mnie zaskoczyly te 32KB w standardzie.

: Ja tez zdebialem.. Toby oznaczalo ze jednak standard wspiera
: architekture 16 bitowa... Chyba kilka latek za pozno..
Tia, zgadza sie. I to jest kolejny powod, dla ktorego powinienem zerwac
na zawsze z tym jezykiem.

: Z drugiej strony widzialem w jednym miejscu w kodzie rodem z 
: Suna patch zamieniajacy 32767 na 60000... 
: Czyzby standard sie juz to jednak zmienil na 64KB ?
Jak juz wczesniej o tym wspominalem, nalezy uzywac dobrych kompilatorow.

Trzeba tutaj rowniez stwierdzic, ze ANSI C to jest MINIMUM! To znaczy, ze
kompilatory musza honorowac owe zapisy. Szkoda tylko, ze jest ich tak malo.
Chwilami nie wiem, czy takie archaiczne zapisy pozostawiono po to, zeby
mozna bylo kompilowac stare programy, czy tez zeby mozna bylo dzis pisane
programy kompilowac na archaicznych kompilatorach. Przy takim rozwoju
informatyki, jaki obserwujemy obecnie uzywanie takich kompilatorow to po
prostu lamerstwo i dziadostwo. Wspolczesnie szanujace sie kompilatory
powinny byc kompilatorami obu jezykow, C i C++. W zwiazku z tym powinny
byc zgodne z ANSI C++. A jezeli kompilator C++ pozwala na takie rzeczy, jak
przydzielanie duzej ilosci pamieci (czy chociazby komentarze C++), to
dlaczego nie mialby na to pozwalac kompilator C ?

No wiec nie wiem. Jezeli ostatni ANSI C pochodzi z 1988 roku - jak to ktos
tutaj sugerowal - to owa data mowi chyba sama za siebie. Rok wczesniej (a
moze nawet w tym samym roku) wyszla River Raid na male atari (i na reszte
"malych" pewnie tez w tym czasie). A wiec ?

A wiec albo C jest juz przestarzaly i nie ma co go uzywac, albo czas na
nowy standard ANSI C.


-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

Maciej MOCHOL <mmochol@elka.pw.edu.pl> wrote:
: On Wed, 21 Jan 1998, Marek Kotowski wrote:
:> "glowna"  :-)).  I  jeszcze  jedno:  w  kilku  postingach
:> zauwazylem swojego czasu nastepujaca definicje main
:> 
:> void main(void)
:> ...
:> 
:> To blad.  Funkcja main  powinna byc  zawsze typu int. Tak
:> stanowi standard.  Roznica  ma  znaczenie  dla  sekwencji
:> wolajacej i konczacej funkcje main. Dzialanie programu, w
:> ktorym main  ma typ void, jest - formalnie rzecz biorac -
:> niezdefiniowane.

: Na wiekszosci maszyn zwracanie argumentu funkcji jest realizowane
: przez - zazwyczaj - rejestry. Nie ma to __zadnego__ wplywu na 
: sekwencje wolajaca, maja natomiast argumenty wejsciowe - stos.
: void main(void) jest stosowane w bardzo wielu programach i ma na 
: celu podkreslenie ze sie nie zwraca zadnych wartosci.

Ja juz sie raz wypowiadalem na temat zwracania wartosci przez funkcje main.

Zeby sie nie "powtarzac drugi raz", przypomne szanownym kolegom, ze funkcji
main nie wywoluje zadna funkcja w programie, lecz SYSTEM! A system ma swoja
deklaracje funkcji main:

int main( int argc, char** argv, char** envp );

i co go to obchodzi, ze ktos sobie zadeklaruje

void main( void );

Dla systemu jedyna rzecz to przekazac w/w parametry do owej funkcji i zabrac
ze stosu, wzglednie odczytac z rejestru procesora odpowiednia wartosc.
System nic nie interesuje to, ze ktos napisal sobie void. Po prostu zbierze
sobie wartosc. I nawet ewentualnie ja sobie nawet zinterpretuje.
Pisalem juz zreszta o tym, jak ma zwyczaj interpretowac owa wartosc AmigaDOS.

Dlatego tez funkcje main nalezy ZAWSZE W KAZDYM PRZYPADKU deklarowac ze
zwracanym typem wartosci int i na koncu programu umieszczac "return 0".
Ewentualnie inna wartosc, jaka sie chce zwrocic systemowi.


-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

On 2 Feb 1998, Michal Malecki wrote:

> Dlatego tez funkcje main nalezy ZAWSZE W KAZDYM PRZYPADKU deklarowac ze
> zwracanym typem wartosci int i na koncu programu umieszczac "return 0".
> Ewentualnie inna wartosc, jaka sie chce zwrocic systemowi.
> 

Alez Wy jestescie uparci... To zobaczcie sobie w ksiazce Stroustrupa,
jak mu sie nie chce wysilac i jak pisze

main()
{
 costam costam
... 
}

I nie konczy programow return 0. W ten sposob robi smiertelny
blad, bo przeciez system dostaje __LOSOWA__ wartosc. Co za lamer z 
niego...

pozdrawiam
c.

PS. wiem co to znaczy main() i czym sie rozni od void main(void)

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Maciej MOCHOL <mmochol@elka.pw.edu.pl> wrote:
: On 2 Feb 1998, Michal Malecki wrote:

:> Dlatego tez funkcje main nalezy ZAWSZE W KAZDYM PRZYPADKU deklarowac ze
:> zwracanym typem wartosci int i na koncu programu umieszczac "return 0".
:> Ewentualnie inna wartosc, jaka sie chce zwrocic systemowi.
:> 

: Alez Wy jestescie uparci... To zobaczcie sobie w ksiazce Stroustrupa,
: jak mu sie nie chce wysilac i jak pisze

: main()
: {
:  costam costam
: ... 
: }

: I nie konczy programow return 0. W ten sposob robi smiertelny
: blad, bo przeciez system dostaje __LOSOWA__ wartosc. Co za lamer z 
: niego...

Nie wiem, czy zauwazyles, ale taka funkcja domyslnie zwraca int.
A kompilator juz ci w tym momencie dwa ostrzezenia generuje.



-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

On 4 Feb 1998, Michal Malecki wrote:

> Nie wiem, czy zauwazyles, ale taka funkcja domyslnie zwraca int.
> A kompilator juz ci w tym momencie dwa ostrzezenia generuje.

Chyba napisalem wyraznie ze wiem czym sie rozni main() od void main(void).
Kompilator zadnego ostrzezenia nie generuje (gcc), nawet z opcja -Wall.
Wiem wiem, do kitu kompilator...

pozdrawiam
c.

PS. Natomiast przy funkcji innej niz main ostrzega o braku rezultatu.

--
Codematic                            
 code@beta.cku.pwr.wroc.pl.strasznie.mi.sie.podobaja
 mmochol@elka.pw.edu.pl.te.smieci.na.koncu.adresu.email
 http://home.elka.pw.edu.pl.i.www.rowniez/~mmochol

Maciej MOCHOL <mmochol@elka.pw.edu.pl> wrote:
: On 4 Feb 1998, Michal Malecki wrote:

:> Nie wiem, czy zauwazyles, ale taka funkcja domyslnie zwraca int.
:> A kompilator juz ci w tym momencie dwa ostrzezenia generuje.

: Chyba napisalem wyraznie ze wiem czym sie rozni main() od void main(void).
: Kompilator zadnego ostrzezenia nie generuje (gcc), nawet z opcja -Wall.
: Wiem wiem, do kitu kompilator...

Jak na razie, ostrzezenia generowal mi wlasnie gcc.
To znaczy - zeby nie bylo nieporozumien - przy deklaracji:
main()
Zglasza ostrzezenie, ze: 1. nie napisano typu wyniku.
2. funkcja zadeklarowana, ze ma cos zwracac, nic nie zwraca.


-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

While testing the million monkey theory, Michal Malecki wrote:
>main()
>Zglasza ostrzezenie, ze: 1. nie napisano typu wyniku.
A dokladniej, ze return type of main is not int.

Kris
-- 
Krzysztof G. Baranowski - Prezes Klubu Nieszkodliwych Manjaków
"Smith & Wesson - The original point and click interface..."
http://www.knm.org.pl/              <prezes@manjak.knm.org.pl>

Krzysztof G. Baranowski <kgb@manjak.knm.org.pl> wrote:
: While testing the million monkey theory, Michal Malecki wrote:
:>main()
:>Zglasza ostrzezenie, ze: 1. nie napisano typu wyniku.
: A dokladniej, ze return type of main is not int.
Nie kolego. Ze return-type defaults to `int'.

Osobiscie sprawdzilem, jak to jest.

W C++ mozna pisac:
main()
{
	return 0;
}

jak rowniez nie zwracac wartosci w main i kompilator nawet nie miauknie
(choc szczerze mowiac, nie wiem, co on systemowi wtedy zwraca).

Natomiast w C otrzymasz owe ostrzezenia.


-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

While testing the million monkey theory, Michal Malecki wrote:
>Krzysztof G. Baranowski <kgb@manjak.knm.org.pl> wrote:
>: While testing the million monkey theory, Michal Malecki wrote:
>:>main()
>:>Zglasza ostrzezenie, ze: 1. nie napisano typu wyniku.
>: A dokladniej, ze return type of main is not int.
>Nie kolego. Ze return-type defaults to `int'.
>Osobiscie sprawdzilem, jak to jest.
>W C++ mozna pisac:
[...]
>Natomiast w C otrzymasz owe ostrzezenia.
Tez o C pisalem. Ale ja mowilem o takim przypadku: :)

[root@manjak /root]# echo "void main(void) { }" > plik.c;  gcc -Wall plik.c
plik.c:1: warning: return type of `main' is not `int'
[root@manjak /root]# echo "void main(void) { }" > plik.c;  g++ -Wall plik.c
plik.c:1: warning: return type for `main' changed to `int'


W przypadku samego main, kompilatory zachowuja sie nastepujaco:
[root@manjak /root]# echo "main(void) { }" > plik.c;  gcc -Wall plik.c
plik.c:1: warning: return-type defaults to `int'
plik.c: In function `main':
plik.c:1: warning: control reaches end of non-void function
[root@manjak /root]# echo "main(void) { }" > plik.c;  g++ -Wall plik.c
[root@manjak /root]#

Gwoli scislosci:

[root@manjak /root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/egcs-2.90.21/specs
gcc version egcs-2.90.21 971202 (egcs-1.00 release)

Kris
-- 
Krzysztof G. Baranowski - Prezes Klubu Nieszkodliwych Manjaków
"Smith & Wesson - The original point and click interface..."
http://www.knm.org.pl/              <prezes@manjak.knm.org.pl>

Krzysztof G. Baranowski <kgb@manjak.knm.org.pl> wrote:
: Tez o C pisalem. Ale ja mowilem o takim przypadku: :)

: [root@manjak /root]# echo "void main(void) { }" > plik.c;  gcc -Wall plik.c
: plik.c:1: warning: return type of `main' is not `int'
: [root@manjak /root]# echo "void main(void) { }" > plik.c;  g++ -Wall plik.c
: plik.c:1: warning: return type for `main' changed to `int'
Zgadza sie, kolego. Z tym tylko zastrzezeniem, ze mowilem tu o 'main()', a nie
'void main()'. Niemmiej jednak to, co napisales dokladnie potwierdza to, co
pisalem na temat funkcji main. Dziekuje.

: W przypadku samego main, kompilatory zachowuja sie nastepujaco:
: [root@manjak /root]# echo "main(void) { }" > plik.c;  gcc -Wall plik.c
: plik.c:1: warning: return-type defaults to `int'
: plik.c: In function `main':
: plik.c:1: warning: control reaches end of non-void function
: [root@manjak /root]# echo "main(void) { }" > plik.c;  g++ -Wall plik.c
: [root@manjak /root]#

I to jest dokladnie to, o czym pisalem.



-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...