Re: [FUG-BR] RES: C/C++

[Ricardo Nabinger Sanchez]

On Mon, 26 Feb 2007 09:14:09 -0300
Nilson Debatin <[EMAIL PROTECTED]> wrote:

> > Paulo, a função main nem sempre deve retorna um valor, somente se você
> > quiser, quando a função começa com void, significa que não retorna valor
> > nenhum, e ainda você falou que a função main DEVE retornar um valor
> > inteiro, isso também esta errado, a função pode retornar um char, float,
> > double, usigned float...e mais um monte...
> > 
> > Att. 
> 
> Sei que to uns dias atrasados mas quero ser mais um a frisar
> que você está viajando na maionese, a função main **SEMPRE**
> retorna um valor inteiro, você pode até fazer ela void só
> que nesse caso quando seu programa terminar ele VAI SIM 
> retornar um inteiro, o 0. Vai ser sempre sucesso, o que
> nem sempre é verdade dependendo do que o programa fará, se
> quiser andar mais na linha do correto, faça sempre ela int.

Pela semântica da linguagem "void main()" não retorna nada.  Se retornasse
algo, o compilador estaria fazendo algo errado.  E ainda assim, muito depende
da parceria entre compilador e o sistema operacional.  Os padrões querem
que os programas em C funcionem (ou pelo menos compilem) independente do
sistema operacional e compilador.  É difícil garantir isso na prática.

De volta ao main, ele retornará algo útil se o programador assim quiser, ou
então, durante a ligação do programa, o compilador decidirá pelo programador
o que será retornado.  Se o programador não especificou nada, então será
retornado o que estiver ao alcance da mão.

Quem quiser ler adiante, apresento alguns fatos que podem ser interessantes
apenas para curiosos.  Para os demais, basta saber que main é especial para a
fase de ligação do programa (momento de geração do executável), e espera-se
que ela retorne um inteiro para indicar o status de finalização do programa.



% cat main.c
void main() {}
% gcc main.c
main.c: In function `main':
main.c:1: warning: return type of 'main' is not `int'
%  ./a.out 
Exit 16

Claramente 16 não é zero.  O que houve afinal?

% objdump -d a.out
...
0804848c :
 804848c:   55  push   %ebp
 804848d:   89 e5   mov%esp,%ebp
 804848f:   83 ec 08sub$0x8,%esp
 8048492:   83 e4 f0and$0xfff0,%esp
 8048495:   b8 00 00 00 00  mov$0x0,%eax  # eax = 0
 804849a:   83 c0 0fadd$0xf,%eax  # eax = 0xf
 804849d:   83 c0 0fadd$0xf,%eax  # eax = 0x1e
 80484a0:   c1 e8 04shr$0x4,%eax  # eax = 1
 80484a3:   c1 e0 04shl$0x4,%eax  # eax = 16
 80484a6:   29 c4   sub%eax,%esp  # esp -= 16
 80484a8:   c9  leave  
 80484a9:   c3  ret
 80484aa:   90  nop
 80484ab:   90  nop
...


Ainda assim, da onde veio esse 16?  A última instrução executada antes do
programa finalizar foi a do endereço 0x08048326, sendo que a entrada nesse
trecho se deu pelo endereço 0x08048350:

Disassembly of section .plt:
08048320 <.plt>:
 8048320:   ff 35 34 96 04 08   pushl  0x8049634
 8048326:   ff 25 38 96 04 08   jmp*0x8049638
 804832c:   00 00   add%al,(%eax)
 804832e:   00 00   add%al,(%eax)
 8048330:   ff 25 3c 96 04 08   jmp*0x804963c
 8048336:   68 00 00 00 00  push   $0x0
 804833b:   e9 e0 ff ff ff  jmp8048320 <_init+0x14>
 8048340:   ff 25 40 96 04 08   jmp*0x8049640
 8048346:   68 08 00 00 00  push   $0x8
 804834b:   e9 d0 ff ff ff  jmp8048320 <_init+0x14>
 8048350:   ff 25 44 96 04 08   jmp*0x8049644
 8048356:   68 10 00 00 00  push   $0x10
 804835b:   e9 c0 ff ff ff  jmp8048320 <_init+0x14>


O conteúdo dos registradores antes desta última chamada para biblioteca
externa era:
(gdb) info registers
eax0x10 16
ecx0x1  1
edx0x10 16
ebx0x1  1
esp0xbfbfe744   0xbfbfe744
ebp0xbfbfe778   0xbfbfe778
esi0xbfbfe788   -1077942392
edi0x2804e2a0   671408800
eip0x80483260x8048326
eflags 0x282642
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27

Só que neste ponto, a função main já foi executada há muitas instruções
atrás, e não retornou nada pra ninguém.  Mas o ligador não sabe disso, e azar
do programador, pois ele vai ligar a crt0.o de qualquer jeito.  E na crt0.o
se assume que o topo da pilha (e registrador eax, em x86) contém o parâmetro
que será usado como valor de retorno.

Nesse exemplo, tanto a última coisa empilhada (8048356: push $0x10) quanto o
eax contêm 0x0010, ou 16 em base decimal.  O byte menos significati

Re: [FUG-BR] RES: C/C++

[Nilson Debatin]

Em Sáb, 2007-02-24 às 08:40 -0300, Anderson P. Matos - LINHARES ON LINE
escreveu:
> Paulo, a função main nem sempre deve retorna um valor, somente se você
> quiser, quando a função começa com void, significa que não retorna valor
> nenhum, e ainda você falou que a função main DEVE retornar um valor
> inteiro, isso também esta errado, a função pode retornar um char, float,
> double, usigned float...e mais um monte...
> 
> Att. 

Sei que to uns dias atrasados mas quero ser mais um a frisar
que você está viajando na maionese, a função main **SEMPRE**
retorna um valor inteiro, você pode até fazer ela void só
que nesse caso quando seu programa terminar ele VAI SIM 
retornar um inteiro, o 0. Vai ser sempre sucesso, o que
nem sempre é verdade dependendo do que o programa fará, se
quiser andar mais na linha do correto, faça sempre ela int.

[]s
Nilson


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[gethostbyname]

Paulo Pires escreveu:
> On 2/25/07, gethostbyname <[EMAIL PROTECTED]> wrote:
>   
>> Foi mal pessoal. Estava alterando as configurações aqui.
>> Acho que eu dupliquei duas mensagens e fazendo essa lambança também :-)
>> Bom, não entendi muito bem sobre o que você quis dizer com a questão da
>> composição visual e da "outra arrumação".
>> 
>
> Apenas que a composição do texto na norma, tanto na construção da
> frase como na apresentação visual, torna difícil a interpretação do
> que quer dizer.
>   
Compreendi. Foi um erro meu ter misturado o negrito no meio do código,
além de ter duplicado a mensagem.
>   
>> Os compiladores podem até aceitar outros retornos de main além de int,
>> mas isso não é portável. Essa é a minha concepção.
>> 
>
> Até concordo com você, mas é porque nós estamos acostumados com
> máquinas e sistemas que trabalham com números.  Não precisaria ser o
> caso.  Eu não se um CP/M da vida tinha alguma coisa como "exit status"
> de um programa, nem tenho muita dificuldade em imaginar um sistema em
> que um processo retornasse, ao invés de um mero valor, algo que
> pudesse ser interpretado como um comando/ação ou um objeto mais
> complexo.
>   
Esse objeto "mais complexo ou comando" poderia ser enviado ao OS por
outros modos, não? Chamar system, por exemplo. Seria mais prático e
simples, não? Imagine a main retornando algo que não seja o número, que
complicação isso geraria.
>   
>> Estive pesquisando sobre o assunto agora e veja que engraçado:
>>
>>  > FYI, the first Google Usenet msg use of '*void main*' was in 1984:
>>  > http://groups.google.com/group/net.lang.c/msg/644f6489bb23c5ab?hl=en
>> 
>
> Assutador...  Se o PCC (Portable C Compiler, que se destinava a
> encontrar potenciais problemas de portabilidade e encorajar um uso
> elegante e pouco sujeito a problemas da linguagem, e serviu de base
> para ferramentas como lint(1)) aceitava coisas como
>
> struct A { int a, b, c; };
>
> void f(struct A x){
> printf("%d %d %d\n", x);
> }
>
> tenho até medo das outras coisas de que o carinha reclamava não
> conseguir fazer.  Por mais que eu entenda que ainda não houvesse
> padrão naquela época, acho o código acima perigosamente
> "implementation-dependent" para o PCC deixar passar sem abrir o bico.
>   
hehehehe. Isso era em 1984!

gethostbyname
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Paulo Pires]

On 2/25/07, gethostbyname <[EMAIL PROTECTED]> wrote:
> Foi mal pessoal. Estava alterando as configurações aqui.
> Acho que eu dupliquei duas mensagens e fazendo essa lambança também :-)
> Bom, não entendi muito bem sobre o que você quis dizer com a questão da
> composição visual e da "outra arrumação".

Apenas que a composição do texto na norma, tanto na construção da
frase como na apresentação visual, torna difícil a interpretação do
que quer dizer.

> Os compiladores podem até aceitar outros retornos de main além de int,
> mas isso não é portável. Essa é a minha concepção.

Até concordo com você, mas é porque nós estamos acostumados com
máquinas e sistemas que trabalham com números.  Não precisaria ser o
caso.  Eu não se um CP/M da vida tinha alguma coisa como "exit status"
de um programa, nem tenho muita dificuldade em imaginar um sistema em
que um processo retornasse, ao invés de um mero valor, algo que
pudesse ser interpretado como um comando/ação ou um objeto mais
complexo.

> Estive pesquisando sobre o assunto agora e veja que engraçado:
>
>  > FYI, the first Google Usenet msg use of '*void main*' was in 1984:
>  > http://groups.google.com/group/net.lang.c/msg/644f6489bb23c5ab?hl=en

Assutador...  Se o PCC (Portable C Compiler, que se destinava a
encontrar potenciais problemas de portabilidade e encorajar um uso
elegante e pouco sujeito a problemas da linguagem, e serviu de base
para ferramentas como lint(1)) aceitava coisas como

struct A { int a, b, c; };

void f(struct A x){
printf("%d %d %d\n", x);
}

tenho até medo das outras coisas de que o carinha reclamava não
conseguir fazer.  Por mais que eu entenda que ainda não houvesse
padrão naquela época, acho o código acima perigosamente
"implementation-dependent" para o PCC deixar passar sem abrir o bico.

-- 
Um abraço.
Paulo A. P. Pires

... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[gethostbyname]

Thiago Costa escreveu:
>
> Eu costumava usar o Jed, muito bom mesmo. Hj em dia prefiro usar ferramentas 
> gráficas como o KDevelop, que também é muito bom, o que realmente ajuda é o 
> word-completation, que evita muitos erros de digitação no código. Mas se 
> precisar editar um código em modo texto eu vou pelo VI mesmo que já estou 
> acostumado a usa-lo para a maioria das coisas.
>
>   

Estou ansioso para ver o Anjuta 2.x estável. Eu tentei usar a versão
instável 2.0.2: demorei um tempo grande para compilar no FreeBSD, não
deu para usar porque realmente era muito instável, mas deu para perceber
que esse Anjuta 2.x vai ficar bonito.
Nunca me animei a usar o KDevelop. A disposição das ferramentas é muito
desorganizada e nas versões que experimentei, ele tentava forçar um
Qtzinho na gente.

gethostbyname
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Thiago Costa]

Em Domingo 25 Fevereiro 2007 00:58, gethostbyname escreveu:
>
> Mudando de assunto, vocês usando quais ferramentas para programação? Emacs?
>
> falou,
> gethostbyname
>
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Eu costumava usar o Jed, muito bom mesmo. Hj em dia prefiro usar ferramentas 
gráficas como o KDevelop, que também é muito bom, o que realmente ajuda é o 
word-completation, que evita muitos erros de digitação no código. Mas se 
precisar editar um código em modo texto eu vou pelo VI mesmo que já estou 
acostumado a usa-lo para a maioria das coisas.

-- 
THIAGO DE SOUZA COSTA

e-mail: [EMAIL PROTECTED]
jid: [EMAIL PROTECTED]
fotolog: http://fotolog.com/thiagodk
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[gethostbyname]

Paulo Pires escreveu:
> Eu não se se foi coisa da lista, mas aqui apareceu um monte de
> asteriscos (acho que você que usou negritos), fazendo parecer
> ponteiros; eu achei um PDF do padrão através do Google (talvez o mesmo
> que você achou, em
> ), onde vi que
> eu não estava louco com um bando de ponteiros. :)
>
> Mas veja o ponto-e-vírgula antes de "or some other
> implementation-defined manner".  Visualmente, acho que outra arrumação
> poderia aumentar mais a clareza, mas o que entendo é que uma
> implementação "hosted" (isto é, aquela que executa em um sistema
> operacional) pode optar entre retornar int _ou_ "alguma outra maneira
> definida pela implementação".  Se optar por int, então deve aceitar
> int main(void){/*...*/} *e* int main(int argc, char *argv[]){/*...*/}.
>  Mas que o fraseamento e a composição visual não ajudam na clareza,
> não ajudam mesmo.
>
>   

Foi mal pessoal. Estava alterando as configurações aqui.
Acho que eu dupliquei duas mensagens e fazendo essa lambança também :-)
Bom, não entendi muito bem sobre o que você quis dizer com a questão da
composição visual e da "outra arrumação".

Os compiladores podem até aceitar outros retornos de main além de int,
mas isso não é portável. Essa é a minha concepção.

Estive pesquisando sobre o assunto agora e veja que engraçado:

 > FYI, the first Google Usenet msg use of '*void main*' was in 1984:
 > http://groups.google.com/group/net.lang.c/msg/644f6489bb23c5ab?hl=en

gethostbyname
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Paulo Pires]

On 2/25/07, gethostbyname <[EMAIL PROTECTED]> wrote:
> Mudando de assunto, vocês usando quais ferramentas para programação? Emacs?

Não.  Eu sempre usei o vi que vinha com o BSD (nvi) e compilava tudo
na linha de comando mesmo.  Como eu comecei com Turbo C, acostumei-me
a usar "syntax-highlighting", e passei a usar vim, para ter esse
recurso.  Nunca usei e-macs além de uns poucos testes, há mais de dez
anos.

Já tentei IDEs para UNIX.  Achei todos pesados e pouco producentes, e
voltei à combinação emulador de terminal (ou
console)+shell+{,n}vi{,m}+gcc/g++/make/rcs.  Mas, é claro, eu não faço
sistemas de grande porte, que justificariam um ambiente mais cheio de
gueriguéris.

-- 
Um abraço.
Paulo A. P. Pires

... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Diego Aranha]

Depende do tamanho do projeto.

Se for pequeno, uso o vi/vim mesmo.
Se não for, gosto do Eclipse (o que eu realmente gosto nele é aquele Navigator 
do lado esquerdo da janela). :)

--
Diego Aranha

> Mudando de assunto, vocês usando quais ferramentas para programação? Emacs?
>
> falou,
> gethostbyname
>
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Paulo Pires]

On 2/25/07, gethostbyname <[EMAIL PROTECTED]> wrote:
>
> Essa exigência não é apenas da linguagem C++:
>
> "*ISO/IEC 9899:1999 (E)(c)ISO/IEC*
>
> *5.1.2.2.1 Program startup*
> The function called at program startup is named main. The implementation
> declares no prototype for this function. It shall be defined **with a
> return type of int** and with no parameters:
> *int *main(void) { /*...*/ }
> or with two parameters (referred to here as argc and argv, though any
> names may be used, as they are local to the function in which they are
> declared):
> *int *main(int argc, char *argv[]) { /*...*/ }
> or equivalent [ver a Nota]; or in some other implementation-defined manner.
>
> *Nota*:
> Thus, int can be replaced by a typedef name defined as int,or the type
> of argv can be written as char ** argv, and so on."

Eu não se se foi coisa da lista, mas aqui apareceu um monte de
asteriscos (acho que você que usou negritos), fazendo parecer
ponteiros; eu achei um PDF do padrão através do Google (talvez o mesmo
que você achou, em
), onde vi que
eu não estava louco com um bando de ponteiros. :)

Mas veja o ponto-e-vírgula antes de "or some other
implementation-defined manner".  Visualmente, acho que outra arrumação
poderia aumentar mais a clareza, mas o que entendo é que uma
implementação "hosted" (isto é, aquela que executa em um sistema
operacional) pode optar entre retornar int _ou_ "alguma outra maneira
definida pela implementação".  Se optar por int, então deve aceitar
int main(void){/*...*/} *e* int main(int argc, char *argv[]){/*...*/}.
 Mas que o fraseamento e a composição visual não ajudam na clareza,
não ajudam mesmo.

-- 
Um abraço.
Paulo A. P. Pires

... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[gethostbyname]

Paulo Pires escreveu:
> Você está fazendo alguma confusão.  C89 é ANSI, cujo correspondente
> ISO (praticamente idêntico, apenas recredenciado) é o C90.
>
>   
Exatamente. Foi um equívoco: C90[ISO - o padrão ANSI com pequenas
modificações] por C89 [ANSI].
>> Teve um cara que liberou o C Completo e Total na rede um tempo atrás.
>> Puxa, logo o livro do Herbert Schildt, o pior autor de todos os tempos.
>> 
>
> Não sei se é *o* pior, mas é um cara que claramente escreve sobre o
> que ele acha que vai lhe render uns trocados.  É provável que o
> compromisso dele seja mais com fazer dinheiro rapidamente do que com a
> qualidade do que escreve.  Nessa linha, o mais lamentável é quando, ao
> invés de ensinar a linguagem de programação a que se propõe na capa,
> ele começa a fazer apologia de determinadas tecnologias e de certos
> fabricantes de software (sobretudo do estado de Washington), talvez a
> fim de dar impulso a outros de seus livros.
>   
Acho que o pior é um livro de "C++" dele cuja boa parte é uma introdução
a C, que por sua vez é a cópia de alguns capítulos do C Completo e Total.
>> PS. A função main não retornar um valor é considerado um ERRO NÃO-FATAL.
>> 
>
> Eu freqüentemente compilo com "-Werror -Wall"; existem motivos para
> que o compilador emita warinings, ou eles não estariam lá.  Um exemplo
> que volta e meia acontece comigo é usar "=" em lugar de "=="; às vezes
> é intencional e às vezes por distração ou erro de digitação, mas um
> warning é bem-vindo nos dois casos.  Todos sabemos fazer e às vezes
> somos forçados a fazer bacalhaus no código, mas também sabemos como
> usar a linguagem para, de forma sintaticamente correta e
> estilisticamente mais produtiva (no sentido de dar clareza que
> facilite a manutenção de código no futuro), fazer calar qualquer
> warning, mesmo quando se usa "-pedantic".
>
>   
Mudando de assunto, vocês usando quais ferramentas para programação? Emacs?

falou,
gethostbyname


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[gethostbyname]

Essa exigência não é apenas da linguagem C++:

"*ISO/IEC 9899:1999 (E)©ISO/IEC*

*5.1.2.2.1 Program startup*
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined **with a
return type of int** and with no parameters:
*int *main(void) { /*...*/ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
*int *main(int argc, char *argv[]) { /*...*/ }
or equivalent; or in some other implementation-defined manner.

*Nota*:
Thus, int can be replaced by a typedef name defined as int,or the type
of argv can be written as char ** argv, and so on."

gethostbyname

Nilton Jose Rizzo escreveu:
>Essa exigencia é da linguagem c++ faça esse exemplo e veja 
>que o erro persiste
>
>
> #include 
>
> void main (void);
>
> void main (void)
> {
>printf ("teste");
> }
>
>   


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[gethostbyname]

Paulo Pires escreveu:
> Você está fazendo alguma confusão.  C89 é ANSI, cujo correspondente
> ISO (praticamente idêntico, apenas recredenciado) é o C90.
>
>   
Exatamente. Foi um equívoco: C90[ISO - o padrão ANSI com pequenas
modificações] por C89 [ANSI].
>> Teve um cara que liberou o C Completo e Total na rede um tempo atrás.
>> Puxa, logo o livro do Herbert Schildt, o pior autor de todos os tempos.
>> 
>
> Não sei se é *o* pior, mas é um cara que claramente escreve sobre o
> que ele acha que vai lhe render uns trocados.  É provável que o
> compromisso dele seja mais com fazer dinheiro rapidamente do que com a
> qualidade do que escreve.  Nessa linha, o mais lamentável é quando, ao
> invés de ensinar a linguagem de programação a que se propõe na capa,
> ele começa a fazer apologia de determinadas tecnologias e de certos
> fabricantes de software (sobretudo do estado de Washington), talvez a
> fim de dar impulso a outros de seus livros.
>   
Acho que o pior é um livro de "C++" dele cuja boa parte é uma introdução
a C, que por sua vez é a cópia de alguns capítulos do C Completo e Total.
>> PS. A função main não retornar um valor é considerado um ERRO NÃO-FATAL.
>> 
>
> Eu freqüentemente compilo com "-Werror -Wall"; existem motivos para
> que o compilador emita warinings, ou eles não estariam lá.  Um exemplo
> que volta e meia acontece comigo é usar "=" em lugar de "=="; às vezes
> é intencional e às vezes por distração ou erro de digitação, mas um
> warning é bem-vindo nos dois casos.  Todos sabemos fazer e às vezes
> somos forçados a fazer bacalhaus no código, mas também sabemos como
> usar a linguagem para, de forma sintaticamente correta e
> estilisticamente mais produtiva (no sentido de dar clareza que
> facilite a manutenção de código no futuro), fazer calar qualquer
> warning, mesmo quando se usa "-pedantic".
>
>   
Mudando de assunto, vocês usando quais ferramentas para programação? Emacs?

falou,
gethostbyname
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[gethostbyname]

Essa exigência não é apenas da linguagem C++:

"*ISO/IEC 9899:1999 (E)©ISO/IEC*

*5.1.2.2.1 Program startup*
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined **with a
return type of int** and with no parameters:
*int *main(void) { /*...*/ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
*int *main(int argc, char *argv[]) { /*...*/ }
or equivalent [ver a Nota]; or in some other implementation-defined manner.

*Nota*:
Thus, int can be replaced by a typedef name defined as int,or the type
of argv can be written as char ** argv, and so on."

gethostbyname

Nilton Jose Rizzo escreveu:
>Essa exigencia é da linguagem c++ faça esse exemplo e veja 
>que o erro persiste
>
>
> #include 
>
> void main (void);
>
> void main (void)
> {
>printf ("teste");
> }
>
>   

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Paulo Pires]

On 2/24/07, gethostbyname <[EMAIL PROTECTED]> wrote:
> Bom, creio que ele deve estar se referindo ao padrão mais atual da
> linguagem, C99. O padrão ANSI já está meio obsoleto pelos padrões ISO
> C89 e C99.

Você está fazendo alguma confusão.  C89 é ANSI, cujo correspondente
ISO (praticamente idêntico, apenas recredenciado) é o C90.

> Teve um cara que liberou o C Completo e Total na rede um tempo atrás.
> Puxa, logo o livro do Herbert Schildt, o pior autor de todos os tempos.

Não sei se é *o* pior, mas é um cara que claramente escreve sobre o
que ele acha que vai lhe render uns trocados.  É provável que o
compromisso dele seja mais com fazer dinheiro rapidamente do que com a
qualidade do que escreve.  Nessa linha, o mais lamentável é quando, ao
invés de ensinar a linguagem de programação a que se propõe na capa,
ele começa a fazer apologia de determinadas tecnologias e de certos
fabricantes de software (sobretudo do estado de Washington), talvez a
fim de dar impulso a outros de seus livros.

> PS. A função main não retornar um valor é considerado um ERRO NÃO-FATAL.

Eu freqüentemente compilo com "-Werror -Wall"; existem motivos para
que o compilador emita warinings, ou eles não estariam lá.  Um exemplo
que volta e meia acontece comigo é usar "=" em lugar de "=="; às vezes
é intencional e às vezes por distração ou erro de digitação, mas um
warning é bem-vindo nos dois casos.  Todos sabemos fazer e às vezes
somos forçados a fazer bacalhaus no código, mas também sabemos como
usar a linguagem para, de forma sintaticamente correta e
estilisticamente mais produtiva (no sentido de dar clareza que
facilite a manutenção de código no futuro), fazer calar qualquer
warning, mesmo quando se usa "-pedantic".

-- 
Um abraço.
Paulo A. P. Pires

... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Paulo Pires]

On 2/24/07, Anderson P. Matos - LINHARES ON LINE
<[EMAIL PROTECTED]> wrote:
> Paulo, a função main nem sempre deve retorna um valor, somente se você
> quiser, quando a função começa com void, significa que não retorna valor
> nenhum, e ainda você falou que a função main DEVE retornar um valor
> inteiro, isso também esta errado, a função pode retornar um char, float,
> double, usigned float...e mais um monte...

Obrigado pela lembrança.  Eu já trabalhei com compilador C para outras
arquiteturas e outros sistemas operacionais, e já fiz muito "void
main()" -- mas nunca um "double main()" -- , mas vale o recado para
que os outros saibam que em C é possível ter outros tipos de retorno
para main() em determinadas situações.

Entretanto, note que eu disse que era um erro em C++, que era a
linguagem do programa original, e disse explicitamente que não seria
indicado como erro em C.  Note também que não estamos falando de
CP/M-80 ou de alguma dispositivo embarcado usando microPIC, mas de
UNIX, onde um comando "return" dentro de main(), mesmo em C, retorna
ao sistema operacional um valor para ser informado como estado de
saída do processo, e que esse valor de estado é um inteiro.

-- 
Um abraço.
Paulo A. P. Pires

... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Nilton Jose Rizzo]

On Sat, 24 Feb 2007 08:40:25 -0300, Anderson P. Matos - LINHARES ON LINE wrote
> Paulo, a função main nem sempre deve retorna um valor, somente se 
> você quiser, quando a função começa com void, significa que não 
> retorna valor nenhum, e ainda você falou que a função main DEVE 
> retornar um valor inteiro, isso também esta errado, a função pode 
> retornar um char, float, double, usigned float...e mais um monte...


   Essa exigencia é da linguagem c++ faça esse exemplo e veja 
   que o erro persiste


#include 

void main (void);

void main (void)
{
   printf ("teste");
}


>g++ -o teste teste.cpp
teste.cpp: In function `int main(...)':
teste.cpp:8: declaration of C function `int main(...)' conflicts with
teste.cpp:4: previous declaration `void main()' here


> 
> Att.
> 
> Anderson P. Matos  
> Analista de Suporte
> Linhares Serviços On-Line
> Tel: (27) 2103-8100
> E-mail: [EMAIL PROTECTED]
> -
> Tel.: (27) 2103-8105 
> Cel: (27) 9936-4186
> E-mail: [EMAIL PROTECTED]  
> Messenger: [EMAIL PROTECTED]
> Skype: andersonpmatos
> 
> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Paulo Pires
> Enviada em: sexta-feira, 23 de fevereiro de 2007 08:00
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] C/C++
> 
> On 2/21/07, Rodrigo Ferreira <[EMAIL PROTECTED]> wrote:
> > Bom dia lista, venho tentando a algum tempo compilar/rodar arquivos .c
> e
> > .cpp, porem não obtive sucesso, antes de migrar para o FreeBSD eu
> > utilizava o turbo c++ no win, e agora no Free estou tentando usar o
> > gcc/g++, só que no programa mais simples que estou tentando fazer
> > aparece erro.
> >
> > Programa teste:
> >
> > #include "/usr/include/stdio.h"
> > #include "/usr/include/conio.h"
> >
> > void main (void)
> > {
> > puts ("Alo Mundo");
> > getch();
> > }
> >
> > dai quando eu dou g++ teste.cpp, aparece esses erros:
> > teste.cpp:2:32: /usr/include/conio.h: No such file or directory
> > teste.cpp:5: error: `main' must return `int'
> > teste.cpp: In function `int main(...)':
> > teste.cpp:7: error: `getch' undeclared (first use this function)
> > teste.cpp:7: error: (Each undeclared identifier is reported only once
> > for each function it appears in.)
> 
> Um dos erros que eu ia apontar já foi apontado pelo compilador C++ 
> (em C não seria indicado como erro): a função main() deve retornar 
> um valor inteiro (int), de modo que tem que ser declarada como "int 
> main()" ou "int main(int argc, char **argv)" (ou ainda "int main(int 
> argc, char *argv[])").  A isso está ligado ou outro erro no seu 
> programa, mas que não está indicado acima: para sair da função que 
> retorna int, você tem obrigatoriamente que ter um comando "return 
> valor;", onde "valor" é uma expressão com valor inteiro (geralmente -
> - especialmente no UNIX -- main() retorna 0 quando é bem sucedido),
>  ou uma chamada "exit(valor);", onde "valor" também é inteiro.
> 
> Quando você está incluindo arquivos de cabeçalho da biblioteca 
> padrão, a convenção é usar '#include ', ao invés de '#include
> "cabeçalho.h"'.  Esta última forma, usando aspas, é usada para
> arquivos de cabeçalho criados pelo próprio programador, para
> distingüi-los dos cabeçalhos padronizados.  Também não é usual 
> colocar o caminho completo dos arquivos, especialmente quando se 
> está usando cabeçalhos da biblioteca padrão (com <>, e não com aspas,
>  pois o compilador sabe como encontrá-los).

Só um parentses nesse bapo, se me permite PAPiris...
o include com <> significa que o compilador irar procurar pelo arquivo
nos PATH padrão de pesquisa (INCLUDE) e com "" só irá pesquisar no 
diretório atual

por exemplo:

#include 

ele irá procurar em /usr/include e /usr/X11R6/include.  Essa procura
é feita adicionando o PATH ao nome do arquivo e o compilador tenta abri-lo
caso vc precise de arquivos system net ou outro qualquer
deve ser feito da forma:

#include 

caso voce queira incluir ou modificar a pesquisa olhe as opções -I (include)
e -L (lib) do gcc
e veja também sobre variáveis de ambiente (INCLUDE/LIB/CC e outras)


> 
> Como outros já disseram, conio.h não é um cabeçalho padrão e a função
> getch(), que seria declarada nesse cabeçalho específico dos
> compiladores da Borland, também não é comumente aceita no UNIX (pelo
> menos não com o mesmo sentido que teria no compilador da Borland).
> Principalmente enquanto você está aprendendo, procure aprender a
> linguagem padrão, ao invés de uma implementação específica.
> 
> Outra coisa: seu arquivo indica programa em C++, mas o código que 
> você escreveu é C.  Não que esteja estritamente errado, mas a minha 
> recomendação pessoal é que se você vai usar apenas C em um módulo de 
> programa, use o compilador C (costuma ser mais rápido) e coloque nos 
> arquivos a extensão ".c", ao invés de ".cpp" ou ".cc".  Ou, então, 
> aprenda logo C++ através de exemplos usando recursos

Re: [FUG-BR] RES: C/C++

[gethostbyname]

Bom, creio que ele deve estar se referindo ao padrão mais atual da
linguagem, C99. O padrão ANSI já está meio obsoleto pelos padrões ISO
C89 e C99.

Teve um cara que liberou o C Completo e Total na rede um tempo atrás.
Puxa, logo o livro do Herbert Schildt, o pior autor de todos os tempos.

PS. A função main não retornar um valor é considerado um ERRO NÃO-FATAL.

gethostbyname

Diego Aranha escreveu:
> Acho que ele estava se referindo ao padrão ANSI:
>
> http://www.delorie.com/djgpp/v2faq/faq22_25.html
>
> E todos nós escrevemos código que respeita os padrões, certo? :)
>
> --
> Diego Aranha
>
> On Saturday 24 February 2007 11:40, Anderson P. Matos - LINHARES ON LINE 
> wrote:
>   
>> Paulo, a função main nem sempre deve retorna um valor, somente se você
>> quiser, quando a função começa com void, significa que não retorna valor
>> nenhum, e ainda você falou que a função main DEVE retornar um valor
>> inteiro, isso também esta errado, a função pode retornar um char, float,
>> double, usigned float...e mais um monte...
>>
>> Att.
>>
>> 

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] RES: C/C++

[Diego Aranha]

Acho que ele estava se referindo ao padrão ANSI:

http://www.delorie.com/djgpp/v2faq/faq22_25.html

E todos nós escrevemos código que respeita os padrões, certo? :)

--
Diego Aranha

On Saturday 24 February 2007 11:40, Anderson P. Matos - LINHARES ON LINE 
wrote:
> Paulo, a função main nem sempre deve retorna um valor, somente se você
> quiser, quando a função começa com void, significa que não retorna valor
> nenhum, e ainda você falou que a função main DEVE retornar um valor
> inteiro, isso também esta errado, a função pode retornar um char, float,
> double, usigned float...e mais um monte...
>
> Att.
>
>
> Anderson P. Matos
> Analista de Suporte
> Linhares Serviços On-Line
> Tel: (27) 2103-8100
> E-mail: [EMAIL PROTECTED]
> -
> Tel.: (27) 2103-8105
> Cel: (27) 9936-4186
> E-mail: [EMAIL PROTECTED]
> Messenger: [EMAIL PROTECTED]
> Skype: andersonpmatos
>
> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Paulo Pires
> Enviada em: sexta-feira, 23 de fevereiro de 2007 08:00
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] C/C++
>
> On 2/21/07, Rodrigo Ferreira <[EMAIL PROTECTED]> wrote:
> > Bom dia lista, venho tentando a algum tempo compilar/rodar arquivos .c
>
> e
>
> > .cpp, porem não obtive sucesso, antes de migrar para o FreeBSD eu
> > utilizava o turbo c++ no win, e agora no Free estou tentando usar o
> > gcc/g++, só que no programa mais simples que estou tentando fazer
> > aparece erro.
> >
> > Programa teste:
> >
> > #include "/usr/include/stdio.h"
> > #include "/usr/include/conio.h"
> >
> > void main (void)
> > {
> > puts ("Alo Mundo");
> > getch();
> > }
> >
> > dai quando eu dou g++ teste.cpp, aparece esses erros:
> > teste.cpp:2:32: /usr/include/conio.h: No such file or directory
> > teste.cpp:5: error: `main' must return `int'
> > teste.cpp: In function `int main(...)':
> > teste.cpp:7: error: `getch' undeclared (first use this function)
> > teste.cpp:7: error: (Each undeclared identifier is reported only once
> > for each function it appears in.)
>
> Um dos erros que eu ia apontar já foi apontado pelo compilador C++ (em
> C não seria indicado como erro): a função main() deve retornar um
> valor inteiro (int), de modo que tem que ser declarada como "int
> main()" ou "int main(int argc, char **argv)" (ou ainda "int main(int
> argc, char *argv[])").  A isso está ligado ou outro erro no seu
> programa, mas que não está indicado acima: para sair da função que
> retorna int, você tem obrigatoriamente que ter um comando "return
> valor;", onde "valor" é uma expressão com valor inteiro (geralmente --
> especialmente no UNIX -- main() retorna 0 quando é bem sucedido), ou
> uma chamada "exit(valor);", onde "valor" também é inteiro.
>
> Quando você está incluindo arquivos de cabeçalho da biblioteca padrão,
> a convenção é usar '#include ', ao invés de '#include
> "cabeçalho.h"'.  Esta última forma, usando aspas, é usada para
> arquivos de cabeçalho criados pelo próprio programador, para
> distingüi-los dos cabeçalhos padronizados.  Também não é usual colocar
> o caminho completo dos arquivos, especialmente quando se está usando
> cabeçalhos da biblioteca padrão (com <>, e não com aspas, pois o
> compilador sabe como encontrá-los).
>
> Como outros já disseram, conio.h não é um cabeçalho padrão e a função
> getch(), que seria declarada nesse cabeçalho específico dos
> compiladores da Borland, também não é comumente aceita no UNIX (pelo
> menos não com o mesmo sentido que teria no compilador da Borland).
> Principalmente enquanto você está aprendendo, procure aprender a
> linguagem padrão, ao invés de uma implementação específica.
>
> Outra coisa: seu arquivo indica programa em C++, mas o código que você
> escreveu é C.  Não que esteja estritamente errado, mas a minha
> recomendação pessoal é que se você vai usar apenas C em um módulo de
> programa, use o compilador C (costuma ser mais rápido) e coloque nos
> arquivos a extensão ".c", ao invés de ".cpp" ou ".cc".  Ou, então,
> aprenda logo C++ através de exemplos usando recursos próprios do C++,
> se quiser usar os recursos que essa linguagem oferece antes de ficar
> "viciado" em C puro e simples.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] RES: C/C++

[Anderson P. Matos - LINHARES ON LINE]

Paulo, a função main nem sempre deve retorna um valor, somente se você
quiser, quando a função começa com void, significa que não retorna valor
nenhum, e ainda você falou que a função main DEVE retornar um valor
inteiro, isso também esta errado, a função pode retornar um char, float,
double, usigned float...e mais um monte...

Att. 

 
Anderson P. Matos  
Analista de Suporte
Linhares Serviços On-Line
Tel: (27) 2103-8100
E-mail: [EMAIL PROTECTED]
-
Tel.: (27) 2103-8105 
Cel: (27) 9936-4186
E-mail: [EMAIL PROTECTED]  
Messenger: [EMAIL PROTECTED]
Skype: andersonpmatos

-Mensagem original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
nome de Paulo Pires
Enviada em: sexta-feira, 23 de fevereiro de 2007 08:00
Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Assunto: Re: [FUG-BR] C/C++

On 2/21/07, Rodrigo Ferreira <[EMAIL PROTECTED]> wrote:
> Bom dia lista, venho tentando a algum tempo compilar/rodar arquivos .c
e
> .cpp, porem não obtive sucesso, antes de migrar para o FreeBSD eu
> utilizava o turbo c++ no win, e agora no Free estou tentando usar o
> gcc/g++, só que no programa mais simples que estou tentando fazer
> aparece erro.
>
> Programa teste:
>
> #include "/usr/include/stdio.h"
> #include "/usr/include/conio.h"
>
> void main (void)
> {
> puts ("Alo Mundo");
> getch();
> }
>
> dai quando eu dou g++ teste.cpp, aparece esses erros:
> teste.cpp:2:32: /usr/include/conio.h: No such file or directory
> teste.cpp:5: error: `main' must return `int'
> teste.cpp: In function `int main(...)':
> teste.cpp:7: error: `getch' undeclared (first use this function)
> teste.cpp:7: error: (Each undeclared identifier is reported only once
> for each function it appears in.)

Um dos erros que eu ia apontar já foi apontado pelo compilador C++ (em
C não seria indicado como erro): a função main() deve retornar um
valor inteiro (int), de modo que tem que ser declarada como "int
main()" ou "int main(int argc, char **argv)" (ou ainda "int main(int
argc, char *argv[])").  A isso está ligado ou outro erro no seu
programa, mas que não está indicado acima: para sair da função que
retorna int, você tem obrigatoriamente que ter um comando "return
valor;", onde "valor" é uma expressão com valor inteiro (geralmente --
especialmente no UNIX -- main() retorna 0 quando é bem sucedido), ou
uma chamada "exit(valor);", onde "valor" também é inteiro.

Quando você está incluindo arquivos de cabeçalho da biblioteca padrão,
a convenção é usar '#include ', ao invés de '#include
"cabeçalho.h"'.  Esta última forma, usando aspas, é usada para
arquivos de cabeçalho criados pelo próprio programador, para
distingüi-los dos cabeçalhos padronizados.  Também não é usual colocar
o caminho completo dos arquivos, especialmente quando se está usando
cabeçalhos da biblioteca padrão (com <>, e não com aspas, pois o
compilador sabe como encontrá-los).

Como outros já disseram, conio.h não é um cabeçalho padrão e a função
getch(), que seria declarada nesse cabeçalho específico dos
compiladores da Borland, também não é comumente aceita no UNIX (pelo
menos não com o mesmo sentido que teria no compilador da Borland).
Principalmente enquanto você está aprendendo, procure aprender a
linguagem padrão, ao invés de uma implementação específica.

Outra coisa: seu arquivo indica programa em C++, mas o código que você
escreveu é C.  Não que esteja estritamente errado, mas a minha
recomendação pessoal é que se você vai usar apenas C em um módulo de
programa, use o compilador C (costuma ser mais rápido) e coloque nos
arquivos a extensão ".c", ao invés de ".cpp" ou ".cc".  Ou, então,
aprenda logo C++ através de exemplos usando recursos próprios do C++,
se quiser usar os recursos que essa linguagem oferece antes de ficar
"viciado" em C puro e simples.

-- 
Um abraço.
Paulo A. P. Pires

... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd



-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] RES: C/C++

[Henrique Berenguel]

teste

-Mensagem original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome
de Rodrigo Ferreira
Enviada em: quarta-feira, 21 de fevereiro de 2007 08:45
Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
Assunto: Re: [FUG-BR] C/C++

gethostbyname wrote:
> Bom, o compilador não vai encontrar o conio.h de maneira alguma mesmo
> porque esse arquivo de cabeçalho é de uma biblioteca específica do
Windows.
> Eu não conheço bem as funções declaradas em conio.h, mas creio que elas
> devam ser bastante obsoletas. Portanto, procure algo melhor.
>
> Sugestões:
>
> * Tente estudar C++ ou JAVA invés de C.
> * Não estude através de qualquer livro que utilize bibliotecas
> específicas do Win, quanto mais bibliotecas obsoletas. Nunca perca tempo
> com Herbert Schmit (eu acho que é assim que se escreve). Você tem que
> ter acesso a alguma biblioteca pública também, mas se não tiver:
> www.ebooksportal.org e tem muitos livros bons em inglês na rede do emule
> também.
> * Não desista do gcc/g++ e do ambiente Linux/FreeBSD. Programar no
> Windows é muito muito mais difícil na minha opinião. O compilador da MS
> é um lixo (embora tenha melhorado muito no VS 2005) e conseguir
> informações em certas áreas é bem mais complicado. Quando você quiser
> alguma informação sobre uma função no FreeBSD, comece pelo arquivo de
> inclusão. Bem mais prático, não?
> * Você não necessitará de uma IDE no FreeBSD já que você pode utilizar o
> vi ou emacs, mas se necessitar: Anjuta ou NetBeans (com).
>
> --
> Veja o comentário no arquivo conio.h do Visual Studio 2005:
>
> *Purpose:
> *   This include file contains the function declarations for
> *   the MS C V2.03 compatible console I/O routines.
> --
> Se você não quiser escutar a minha sugestão n° 1, tudo bem:
> Troque a linha 1 por #include 
> Delete a linha 2 e a linha 7
> Se você estiver utilizando alguma IDE, invés de getch() tente pausar o
> programa através de um debugger.
>
> 1#include "/usr/include/stdio.h"
> 2#include "/usr/include/conio.h"
> 3
> 4void main (void)
> 5{
> 6puts ("Alo Mundo");
> 7getch();
> 8}
>
>
> --
>
> gethostbyname
>
>
>
> Rodrigo Ferreira escreveu:
>   
>> Bom dia lista, venho tentando a algum tempo compilar/rodar arquivos .c e 
>> .cpp, porem não obtive sucesso, antes de migrar para o FreeBSD eu 
>> utilizava o turbo c++ no win, e agora no Free estou tentando usar o 
>> gcc/g++, só que no programa mais simples que estou tentando fazer 
>> aparece erro.
>>
>> Programa teste:
>>
>> #include "/usr/include/stdio.h"
>> #include "/usr/include/conio.h"
>>
>> void main (void)
>> {
>> puts ("Alo Mundo");
>> getch();
>> }
>>
>> dai quando eu dou g++ teste.cpp, aparece esses erros:
>> teste.cpp:2:32: /usr/include/conio.h: No such file or directory
>> teste.cpp:5: error: `main' must return `int'
>> teste.cpp: In function `int main(...)':
>> teste.cpp:7: error: `getch' undeclared (first use this function)
>> teste.cpp:7: error: (Each undeclared identifier is reported only once 
>> for each function it appears in.)
>>
>>
>> eu sei que 1 erro é que ele não esta encontrando o conio.h, mais eu não 
>> consegui localizar ele.
>>
>> Alguem poderia me dar um help para tentar compilar isso?
>>
>> Grato
>> -
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>>   
>> 
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
>
>   
Po pessoal, valeu, consegui compilar com a ajuda de voces.
Era esse empurrãozinho que tava faltando pra mim, grato.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


-- 
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.17.37/682 - Release Date: 12/2/2007
13:23


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd