Discussion:
La hora del sistema
(demasiado antiguo para responder)
Cyc
2003-09-21 12:10:06 UTC
Permalink
Hola a todos,

Estoy a vueltas con las funciones de time.h, pero no encuentro la que me
gustaría encontrar :P, una función que me permita ASIGNAR la fecha del
sistema (cambiarla vamos). Me da igual si toma como parámetro una cadena
tipo "DD/MM/AA", o un número de segundos, o una estructura tm. Tiene que
existir esa función no?? Cual es?

Gracias, y un saludo

Cyc
Klannet
2003-09-21 20:14:45 UTC
Permalink
Post by Cyc
Hola a todos,
Estoy a vueltas con las funciones de time.h, pero no encuentro la que me
gustaría encontrar :P, una función que me permita ASIGNAR la fecha del
sistema (cambiarla vamos). Me da igual si toma como parámetro una cadena
tipo "DD/MM/AA", o un número de segundos, o una estructura tm. Tiene que
existir esa función no?? Cual es?
Gracias, y un saludo
Cyc
Al igual ke existe la funcion gettime pos existe la funcion SETTIME ke
usa tb la estructura time
J.A. Gutierrez
2003-09-22 06:17:39 UTC
Permalink
Cyc <***@hotmail.com> wrote:
: Hola a todos,

: gustaría encontrar :P, una función que me permita ASIGNAR la fecha del
: sistema (cambiarla vamos).

Eso no es una pregunta adecuada al grupo; ya que depende del
sistema operativo.
En todo caso, en Unix puedes usar settimeofday.
--
finger ***@shiva.cps.unizar.es for PGP /
.mailcap tip of the day: / La vida es una carcel
application/ms-tnef; cat '%s' > /dev/null / con las puertas abiertas
text/x-vcard; cat '%s' > /dev/null / (A. Calamaro)
Fernando Arbeiza
2003-09-22 10:32:45 UTC
Permalink
Hola:

On Mon, 22 Sep 2003 06:17:39 +0000 (UTC), J.A. Gutierrez
Post by J.A. Gutierrez
Eso no es una pregunta adecuada al grupo; ya que depende del
sistema operativo.
Grupos donde creo que podrían guiarte más:

es.comp.os.linux.programacion
es.comp.os.ms-windows.programacion
es.comp.os.misc

Ya, no hay mucho donde elegir (echo en falta el es.comp.os.unix).
Post by J.A. Gutierrez
En todo caso, en Unix puedes usar settimeofday.
¿Por cierto, hay alguna función POSIX que permita hacerlo? Porque he
estado buscando y no la encuentro. Ya, ya, está fuera de lugar, pero
aprovechando... ;-)

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Martin J. Sanchez
2003-09-22 12:00:48 UTC
Permalink
On Mon, 22 Sep 2003 12:32:45 +0200, Fernando Arbeiza
Post by Fernando Arbeiza
.....
¿Por cierto, hay alguna función POSIX que permita hacerlo? Porque he
estado buscando y no la encuentro. Ya, ya, está fuera de lugar, pero
aprovechando... ;-)
Las mas usadas son stime y setttimeofday.

stime es conforme a:
SVID, AT&T, X/OPEN

settimeofday es conforme a BSD 4.3

Pero no parece haber ninguna POSIX.

Sigo pensando que este tipo de preguntas no son off-topic, por mucho
que algunos os empeñeis. El objeto de este grupo nunca ha sido
discutir unicamente la libreria estandar de C.
Si alguien pregunta: "como hago X en C?, le dirigis a grupos como
es.comp.windows.programacion o es.comp.linux.programacion cuando alli
es tan offtopic como aqui (alli, como aqui, siempre habra quien piense
que aquel no es un grupo especifico de C).

Un saludo,
Martin.
Fernando Arbeiza
2003-09-22 12:37:29 UTC
Permalink
On Mon, 22 Sep 2003 14:00:48 +0200, Martin J Sanchez
Post by Martin J. Sanchez
Las mas usadas son stime y setttimeofday.
SVID, AT&T, X/OPEN
settimeofday es conforme a BSD 4.3
Ah, muchas gracias. No recordaba stime (si es que alguna vez la conocí).
Post by Martin J. Sanchez
Pero no parece haber ninguna POSIX.
Pues no, no parece.
Post by Martin J. Sanchez
Sigo pensando que este tipo de preguntas no son off-topic, por mucho
que algunos os empeñeis. El objeto de este grupo nunca ha sido
discutir unicamente la libreria estandar de C.
Si alguien pregunta: "como hago X en C?, le dirigis a grupos como
es.comp.windows.programacion o es.comp.linux.programacion
Yo creo que, más o menos, lo que he visto que se suele hacer en este
grupo es:

· Indicar que en C no se puede hacer
· Indicar que se necesitan utilizar las llamadas al sistema
· Dar algún ejemplo de llamadas que lo hacen en algún sistema
· Redirigir a un grupo dedicado al sistema en concreto

Y me parece un buen sistema. ¿Opiniones?
Post by Martin J. Sanchez
cuando alli es tan offtopic como aqui (alli, como aqui, siempre habra
quien piense que aquel no es un grupo especifico de C).
No, no es un grupo específico de C. Pero una llamada al sistema
operativo no pertenece al C sino al sistema operativo (como su propio
nombre indica ;-) y creo que el mejor lugar para discutir el efecto de
esa llamada en un sistema es en un grupo apropiado a ese sistema.
Además, algunas veces existen grupos dedicados a la programación en esos
sistemas; lo que lo hace mucho más apropiado.

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Martin J. Sanchez
2003-09-22 15:41:03 UTC
Permalink
On Mon, 22 Sep 2003 14:37:29 +0200, Fernando Arbeiza
Post by Fernando Arbeiza
On Mon, 22 Sep 2003 14:00:48 +0200, Martin J Sanchez
...
Post by Martin J. Sanchez
Sigo pensando que este tipo de preguntas no son off-topic, por mucho
que algunos os empeñeis. El objeto de este grupo nunca ha sido
discutir unicamente la libreria estandar de C.
Si alguien pregunta: "como hago X en C?, le dirigis a grupos como
es.comp.windows.programacion o es.comp.linux.programacion
Yo creo que, más o menos, lo que he visto que se suele hacer en este
· Indicar que en C no se puede hacer
· Indicar que se necesitan utilizar las llamadas al sistema
· Dar algún ejemplo de llamadas que lo hacen en algún sistema
· Redirigir a un grupo dedicado al sistema en concreto
Y me parece un buen sistema. ¿Opiniones?
El problema es etiquetar off-topic a cosas que no lo son. Me parece
muy adecuado indicar, que el uso de X no pertenece a la libreria
estandar, o que tal cosa no se puede realizar con la libreria
estandar, pero este grupo no se dedica exclusivamente a discutir el
estandar. Partes del hipotetico hecho de que "solo" el C estandar es
C. Por cierto, cual de los estandares?. Me quieres decir que el C
que usaba hace 20 años no era C y se llamaba ....?. Han existido y
existiran muchas variantes de C, por que C se aplica a programacion en
muy diversos sistemas con requerimientos muy variados.

Creo que a muchos que visitamos este grupo, nos interesan el uso de
librerias o facilidades relacionadas con C, y creo ademas que es muy
importante para los que estan aprendiendo encontrar discusiones de
programacion real en C.

En cuanto a lo de dirigir a grupos especificos, es evidente que es muy
correcto si tal grupo existe. Por ejemplo si alquien pregunta por
sockets de windows es muy adecuado nombrarle los grupos dedicados al
respecto, pero eso no indica (para mi), que sea un tema off-topic
aqui, por cuanto se usa C. Aunque si existen grupos en castellano para
un tema en concreto, lo logico es desarrollar alli la conversacion.
Por ejemplo, en es.comp.lenguajes.c++, cuando se preguntan por temas
de C, se indica la existencia de este grupo, pero nunca se puede decir
que alli esas preguntas sean off-topic.

Lo de cambiar el Followup-To, para que la conversacion siga en otro
grupo, es inaceptable (a no ser que uno sea el originador del thread)
y resalte la redireccion en el mensaje.

Algo que tampoco me parece correcto es que se modifique el subject de
un mensaje para incluir un OT. Entre otras cosas: muchos lectores de
news lo consideran otro thread, evita que usemos filtros de forma
adecuada, y ademas el off-topic suele ser mas que discutible. Puede
que esta practica sea valida en grupos donde hay mucha actividad, pero
no es el caso de es.comp.lenguajes.c.
Post by Fernando Arbeiza
Post by Martin J. Sanchez
cuando alli es tan offtopic como aqui (alli, como aqui, siempre habra
quien piense que aquel no es un grupo especifico de C).
No, no es un grupo específico de C. Pero una llamada al sistema
operativo no pertenece al C sino al sistema operativo (como su propio
nombre indica ;-) y creo que el mejor lugar para discutir el efecto de
esa llamada en un sistema es en un grupo apropiado a ese sistema.
Además, algunas veces existen grupos dedicados a la programación en esos
sistemas; lo que lo hace mucho más apropiado.
Toda interaccion con el sistema se traduce en llamadas al sistema,
incluidas las streams, sin embargo esto no indica que no sea C. Puede
venir en una libreria C del compilador, puede que tengas que enlazar
con librerias C del sistemas operativo, etc. Pero el uso se hace en C,
con la sintaxis de C, y en un entorno de un programa C.

Para mi resultaria off-topic una discusion sobre el sistema de
seguridad de NT (p.ej). Pero no seria off-topic si se discute una
implementacion en C que use tal sistema.

Tambien tienes que tener en cuenta, que la nueva administracion de la
jerarquia es.* no admite la creacion de grupos especificos si no se
cumplen ciertos criterios que ni siquiera es.comp.lenguajes.c cumple
(numero de mensajes diarios).

Por ejemplo, hace poco propuse o quise proponer la creacion de
es.comp.corba (un grupo que esperaba desde hace tiempo), y segun los
criterios que los administradores de es.* me dieron, primero deberia
crear algo como es.comp.lenguajes.objetos y quizas despues de un
tiempo es.comp.lenguajes.objetos.corba (a pesar de que CORBA no es un
lenguaje y de que se discutirian tecnologias no afines a CORBA).

No pretendo dictar lo que es y no es off-topic en este grupo.
Simplemente es una opinion, basada en el uso que de
es.comp.lenguajes.c se ha estado haciendo durante años, y en su
RFD/RFV (actualmente parece no estar disponible). Todos nosotros y los
que vengan, deberiamos aclarar como queremos usar y que queremos que
sea este grupo.

Un saludo,
Martin.
Julián Albo
2003-09-22 16:09:27 UTC
Permalink
Post by Martin J. Sanchez
Creo que a muchos que visitamos este grupo, nos interesan el uso de
librerias o facilidades relacionadas con C, y creo ademas que es muy
importante para los que estan aprendiendo encontrar discusiones de
programacion real en C.
A mi me pueden interesar muchos temas, pero para ello leo otros grupos.

Y se puede hacer y se hace programación real sin usar más medios que la
librería estándar.

Y me parece que se confunde más a los novatos mezclando el C estándar
con las librerías específicas de los sistemas, así se ve a menudo a
gente quejándose de que no le va el conio.h y cosas similares.
Post by Martin J. Sanchez
Algo que tampoco me parece correcto es que se modifique el subject de
un mensaje para incluir un OT. Entre otras cosas: muchos lectores de
news lo consideran otro thread, evita que usemos filtros de forma
adecuada, y ademas el off-topic suele ser mas que discutible.
Todo es discutible, pero no por no ser discutibles se puede dejar de
tomar decisiones. Además muchas veces si se pone el [OT] es por que se
considera que *la respuesta* es off-topic, independientemente de que la
pregunta lo fuera o no.
Post by Martin J. Sanchez
Toda interaccion con el sistema se traduce en llamadas al sistema,
Vale, y el código fuente se traduce a código máquina, hablemos pues de
ensamblador ;)

Salu2
Martin J. Sanchez
2003-09-22 17:28:57 UTC
Permalink
Post by Julián Albo
Post by Martin J. Sanchez
Creo que a muchos que visitamos este grupo, nos interesan
el uso de librerias o facilidades relacionadas con C,
y creo ademas que es muy importante para los que
estan aprendiendo encontrar discusiones de programacion real en C.
Y se puede hacer y se hace programación real sin usar más medios que
la librería estándar.
Esto se ha discutido antes, pero a que encuentras muy pocos programas no
triviales que solo usen la libreria estandar?
Post by Julián Albo
Y me parece que se confunde más a los novatos mezclando el C
estándar con las librerías específicas de los sistemas, así
se ve a menudo a gente quejándose de que no le va el conio.h
y cosas similares.
^
Desde luego que es importante advertir de lo que es estandar y de lo que
no es. Pero es mejor decirles como se haria en un sistema que decirles
que utilizando C no se puede hacer.
Post by Julián Albo
Post by Martin J. Sanchez
Algo que tampoco me parece correcto es que se modifique el subject
de un mensaje para incluir un OT. Entre otras cosas: muchos
lectores de news lo consideran otro thread, evita que usemos
filtros de forma adecuada, y ademas el off-topic suele ser
mas que discutible.
Todo es discutible, pero no por no ser discutibles se puede
dejar de tomar decisiones. Además muchas veces si se pone el
[OT] es por que se considera que *la respuesta* es off-topic,
independientemente de que la pregunta lo fuera o no.
Puede que en estos casos sea logico pensar en poner un OT, pero si yo
tengo un filtro para los OT, no me enterare de que me respondes.
Post by Julián Albo
Post by Martin J. Sanchez
Toda interaccion con el sistema se traduce en llamadas al sistema,
Vale, y el código fuente se traduce a código máquina, hablemos
pues de ensamblador ;)
Estas infiriendo de forma incorrecta ;.) Lo que estoy diciendo es que no
por que se hagan llamadas al sistema deja de usarse C.

Un saludo,
Martin.
Julián Albo
2003-09-22 17:59:12 UTC
Permalink
Post by Martin J. Sanchez
Post by Julián Albo
Post by Martin J. Sanchez
y creo ademas que es muy importante para los que
estan aprendiendo encontrar discusiones de programacion real en C.
Y se puede hacer y se hace programación real sin usar más medios que
la librería estándar.
Esto se ha discutido antes, pero a que encuentras muy pocos programas no
triviales que solo usen la libreria estandar?
No veo que problema representa eso para un principiante. El caso es que
es perfectamente posible practicar todos los aspectos del lenguaje sin
recurrir a nada externo.
Post by Martin J. Sanchez
Post by Julián Albo
Y me parece que se confunde más a los novatos mezclando el C
estándar con las librerías específicas de los sistemas, así
se ve a menudo a gente quejándose de que no le va el conio.h
y cosas similares.
^
Desde luego que es importante advertir de lo que es estandar y de lo que
no es. Pero es mejor decirles como se haria en un sistema que decirles
que utilizando C no se puede hacer.
A mi me parece mejor redirigirles a un grupo más adecuado, donde pueden
discutirse los diferentes medios que pueda haber en su sistema para esa
tarea. Sin olvidar que muchos ni se molestan en decir cual es sus
sistema operativo ni su compilador.
Post by Martin J. Sanchez
Puede que en estos casos sea logico pensar en poner un OT, pero si yo
tengo un filtro para los OT, no me enterare de que me respondes.
No veo el problema, precisamente para eso unos ponen el filtro y para
otros ponen el OT ¿no? O sea, si no te interesa una respuesta fuera de
temática, no hay ningún problema en que no leas, aunque fuera a una
pregunta tuya.
Post by Martin J. Sanchez
Post by Julián Albo
Post by Martin J. Sanchez
Toda interaccion con el sistema se traduce en llamadas al sistema,
Vale, y el código fuente se traduce a código máquina, hablemos
pues de ensamblador ;)
Estas infiriendo de forma incorrecta ;.) Lo que estoy diciendo es que no
por que se hagan llamadas al sistema deja de usarse C.
Pero no eres tú quien llama al sistema, o inserta código máquina, lo
hace el compilador de C y las librerías de C, que puedes asumir que las
tienes y te da igual a efectos de uso del lenguaje como se implementen
internamente.

Salu2
Fernando Arbeiza
2003-09-22 18:49:18 UTC
Permalink
Sin olvidar que muchos ni se molestan en decir cual es sus sistema
operativo ni su compilador.
Sólo quería resaltar esta frase que creo que es el quid de la cuestión.
No creo que no se molesten en poner el sistema operativo o el
compilador, sino que nadie se ha molestado en explicarles (o no se han
molestado en aprender) qué forma parte del lenguaje, cuál de lo que
utilizan es una librería adicional[1] y qué es una llamada al sistema.

Por eso creo importante diferenciarlo cuando se pregunta aquí algo que
no pertenece al lenguaje; y pienso que, con la redirección o marcándolo
con un OT, la gente que llegue detrás puede darse cuenta de esta
distinción.

[1] Por poner un ejemplo, a veces me da la sensación de que mucha gente
cree que el getch() de conio.h pertenece al lenguaje, cuando en C no
existen ni la cabecera conio.h ni la función getch().

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Julián Albo
2003-09-22 18:54:37 UTC
Permalink
Post by Fernando Arbeiza
[1] Por poner un ejemplo, a veces me da la sensación de que mucha gente
cree que el getch() de conio.h pertenece al lenguaje, cuando en C no
existen ni la cabecera conio.h ni la función getch().
Muchos. Y para ponerlo peor las versiones unixeras de conio.h que corren
por ahí son bastante malas.

Salu2
Martin J. Sanchez
2003-09-22 20:00:53 UTC
Permalink
...
No me voy a repetir :-)
... Sin olvidar que muchos ni se molestan en decir cual
es sus sistema operativo ni su compilador.
Desde luego esto no deja de sorprenderme. Hacen el minimo esfuerzo para
preguntar esperando el maximo esfuerzo del que responda.
Post by Martin J. Sanchez
Puede que en estos casos sea logico pensar en poner un OT,
pero si yo tengo un filtro para los OT, no me enterare de que
me respondes.
No veo el problema, precisamente para eso unos ponen el filtro
y para otros ponen el OT ¿no? O sea, si no te interesa una
respuesta fuera de semática, no hay ningún problema en que
no leas, aunque fuera a una pregunta tuya.
Y entonces para que respondes a una pregunta mia?

Estoy de acuerdo con ciertos usos del OT o la redireccion. Por ejemplo:

Subject: [OT] Discusion sobre X en C/C++
Newsgroups: es.comp.lenguajes.c, es.comp.lenguajes.c++
Follows-up: es.comp.misc
Texto:
-----------------------
Me gustaria discutir algunos aspectos de X en C/C++
Alquien tiene experiencia?

Atencion: He redirigido la conversacion a es.comp.misc
------------------------



Este me parece un uso correcto y es el aconsejado en
www.ietf.org/rfc/rfc1855.txt

Un saludo,
Martin.
Julián Albo
2003-09-22 20:53:37 UTC
Permalink
Post by Martin J. Sanchez
Post by Julián Albo
No veo el problema, precisamente para eso unos ponen el filtro
y para otros ponen el OT ¿no? O sea, si no te interesa una
respuesta fuera de semática, no hay ningún problema en que
no leas, aunque fuera a una pregunta tuya.
Y entonces para que respondes a una pregunta mia?
El que responde no sabe que filtros tiene el que pregunta.

(snip)
Post by Martin J. Sanchez
Este me parece un uso correcto y es el aconsejado en
www.ietf.org/rfc/rfc1855.txt
Ese es un uso correcto, pero eso no quiere decir que otros no lo sean.

Salu2
Fernando Arbeiza
2003-09-22 17:23:47 UTC
Permalink
On Mon, 22 Sep 2003 17:41:03 +0200, Martin J Sanchez
Post by Martin J. Sanchez
El problema es etiquetar off-topic a cosas que no lo son. Me parece
muy adecuado indicar, que el uso de X no pertenece a la libreria
estandar, o que tal cosa no se puede realizar con la libreria
estandar, pero este grupo no se dedica exclusivamente a discutir el
estandar. Partes del hipotetico hecho de que "solo" el C estandar es
C. Por cierto, cual de los estandares?. Me quieres decir que el C
que usaba hace 20 años no era C y se llamaba ....?.Han existido y
existiran muchas variantes de C, por que C se aplica a programacion en
muy diversos sistemas con requerimientos muy variados.
Bueno, veamos. Hace 20 años había ese problema, quien quería programaba
un compilador con una sintaxis determinada y lo llamaba C, y aquello era
C. Por ello surgió el estándar, para que cuando dijeras C se supiese de
qué se estaba hablando (como todos los estándares). Y como estándar creo
que todos nos referimos el de ANSI/ISO en sus versiones del 89 y del 99
(y que provienen del K&R C). Si el estándar es tan general es porque
precisamiente tiene que poder aplicarse en muy diversos sistemas con
requerimientos muy variados.

Y, como tú mismo has dicho, una variante de C es eso, una variante. Lo
puedes llamar GNU C, Turbo C o poniendo delante de la C lo que quieras.
Post by Martin J. Sanchez
En cuanto a lo de dirigir a grupos especificos, es evidente que es muy
correcto si tal grupo existe. Por ejemplo si alquien pregunta por
sockets de windows es muy adecuado nombrarle los grupos dedicados al
respecto, pero eso no indica (para mi), que sea un tema off-topic
aqui, por cuanto se usa C. Aunque si existen grupos en castellano para
un tema en concreto, lo logico es desarrollar alli la conversacion.
Por ejemplo, en es.comp.lenguajes.c++, cuando se preguntan por temas
de C, se indica la existencia de este grupo, pero nunca se puede decir
que alli esas preguntas sean off-topic.
Lo que pasa es que creo que redirigir ese tipo de conversaciones (o por
lo menos indicar que puede discutirse mucho mejor en otro grupo) creo
que es educativo. Y pienso que es educativo porque así el que pregunta
(y puede que no lo supiese) ve dónde acaba el lenguaje y donde empieza
el sistema operativo. Todos sabemos que las interfaces y su definición
son muy importantes. Y creo que diferenciarlas aquí es necesario.

Y es que los sockets no tienen nada que ver con el C. Los procesos no
tienen nada que ver con el C. Los threads no tienen nada que ver con el
C. Son soluciones del sistema operativo a varios problemas, y que se
utilicen desde C es irrelevante. Se podía discutir la interfaz (devuelve
un entero, toma una estructura...), pero el comportamiento y el efecto
de esas funciones (crear un proceso, un thread o un socket...) es un
problema del sistema operativo, no de C. ¿Y en qué mejor sitio conocen
el comportamiento del sistema operativo que en un grupo donde se discute
ese sistema en concreto?

A mí me encanta poner ejemplos chorras, así que ahí va uno (muy, muy
chorras ;-). Conversación en es.cuerpo.humano:
- ¿Qué pasa si le pongo un volante verde a mi Simca 1000?
- ¿Y a mí que me importa? Pregunta en es.coches.tartanas que es
donde sabrán decirte.
- Ah, es que como mis manos manejan el volante y mis manos
pertenecen al cuerpo humano...

Muy, muy chorras ;-P
Post by Martin J. Sanchez
Lo de cambiar el Followup-To, para que la conversacion siga en otro
grupo, es inaceptable (a no ser que uno sea el originador del thread)
y resalte la redireccion en el mensaje.
Si estás seguro de que pertenece a otro grupo, ¿por qué no? Si alguien
ha preguntado donde le ha dado la gana yo respondo donde quiero ;-)
Post by Martin J. Sanchez
Algo que tampoco me parece correcto es que se modifique el subject de
un mensaje para incluir un OT. Entre otras cosas: muchos lectores de
news lo consideran otro thread, evita que usemos filtros de forma
adecuada, y ademas el off-topic suele ser mas que discutible. Puede
que esta practica sea valida en grupos donde hay mucha actividad, pero
no es el caso de es.comp.lenguajes.c.
Pues bueno, visión discutible. Se modifica con OT cuando se ve que el
hilo va a continuar por derroteros que no pertenecen a la temática del
grupo. Yo, por ejemplo, lo consideré así, pues hice una pregunta sobre
una función POSIX. Aunque tienes razón que con el tráfico de este grupo
tampoco es que sea necesario.
Post by Martin J. Sanchez
Toda interaccion con el sistema se traduce en llamadas al sistema,
incluidas las streams, sin embargo esto no indica que no sea C.
Los streams por supuesto que no, puesto que el estándar habla de ellos.
Post by Martin J. Sanchez
Puede venir en una libreria C del compilador, puede que tengas que
enlazar con librerias C del sistemas operativo, etc. Pero el uso se
hace en C, con la sintaxis de C, y en un entorno de un programa C.
Pues sí, y podemos discutir la sintaxis y el entorno de la llamada; pero
el resultado (que será, seguramente, lo que interese al que pregunta) lo
sabrán en un grupo del sistema operativo al que pertenece la llamada.
Por ejemplo, el comportamiento de los threads dependerá de si estamos en
Windows, Linux, Solaris...
Post by Martin J. Sanchez
Para mi resultaria off-topic una discusion sobre el sistema de
seguridad de NT (p.ej). Pero no seria off-topic si se discute una
implementacion en C que use tal sistema.
Tambien tienes que tener en cuenta, que la nueva administracion de la
jerarquia es.* no admite la creacion de grupos especificos si no se
cumplen ciertos criterios que ni siquiera es.comp.lenguajes.c cumple
(numero de mensajes diarios).
Una pena que este grupo no los cumpla. Pero para mensajes que no cumplen
ninguna temática están los grupos misc (digo yo).
Post by Martin J. Sanchez
Por ejemplo, hace poco propuse o quise proponer la creacion de
es.comp.corba (un grupo que esperaba desde hace tiempo), y segun los
criterios que los administradores de es.* me dieron, primero deberia
crear algo como es.comp.lenguajes.objetos y quizas despues de un
tiempo es.comp.lenguajes.objetos.corba (a pesar de que CORBA no es un
lenguaje y de que se discutirian tecnologias no afines a CORBA).
¿Y cuál es el problema? Utilizas es.comp.lenguajes.misc. Cuando el
tráfico crezca mucho, se creará es.comp.lenguajes.objetos; y cuando ya
haya suficiente tráfico, es.comp.lenguajes.objetos.corba. Me parece algo
bastante lógico.
Post by Martin J. Sanchez
No pretendo dictar lo que es y no es off-topic en este grupo.
Simplemente es una opinion, basada en el uso que de
es.comp.lenguajes.c se ha estado haciendo durante años, y en su
RFD/RFV (actualmente parece no estar disponible). Todos nosotros y los
que vengan, deberiamos aclarar como queremos usar y que queremos que
sea este grupo.
Perfecto, en eso estoy completamente de acuerdo. Y creo que he dado mi
opinión. Por si acaso: Creo que en este grupo se debe discutir sobre C
(el estándar, su librería e incluso variantes). También podría
discutirse sobre el uso de librerías externas. Pero el resultado de una
llamada al sistema es objeto de discusión sólo para los que discutan
sobre ese sistema operativo,

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Martin J. Sanchez
2003-09-22 19:28:46 UTC
Permalink
Fernando Arbeiza escribió en mensaje ...
Post by Fernando Arbeiza
On Mon, 22 Sep 2003 17:41:03 +0200, Martin J Sanchez
Post by Martin J. Sanchez
....
Por cierto, cual de los estandares?. Me quieres decir que el C
que usaba hace 20 años no era C y se llamaba ....?.Han existido y
existiran muchas variantes de C, por que C se aplica a programacion en
muy diversos sistemas con requerimientos muy variados.
Bueno, veamos. Hace 20 años había ese problema, quien quería programaba
un compilador con una sintaxis determinada y lo llamaba C, y aquello era
C. Por ello surgió el estándar, para que cuando dijeras C se supiese de
qué se estaba hablando (como todos los estándares). Y como estándar creo
que todos nos referimos el de ANSI/ISO en sus versiones del 89 y del 99
(y que provienen del K&R C).
Como bien dices han existido y existen variaciones importantes en las
implementaciones de C, y como resultado han surgido distintos estandares
que intentan definir lo que encontraras en una implementacion de C
sujeta a uno de esos estandares, u otras peculiaridades (vease POSIX,
X-OPEN, etc). Pero no existe el termino "C estandar", y ni siquiera un
unico estandar de C. Aunque como "C estandar" nos solemos referir a el
"estandar internacional del lenguaje C" de ISO/IEC, que es el "C
programming language standard ISO/IEC 9899" o al "ISO/IEC 9899:1990" con
las correcciones dadas en "ISO/IEC 9899/COR1:1994", ISO/IEC
9899/COR2:1995" y "ISO/IEC 9899/AMD1:1995.

Pero hay que tener en cuenta varios aspectos:
- El estandar especifica las normas que una implementacion
conforme al estandar debe cumplir.
- El propio estandar define varios escenarios que comentan en el
apartado 4. Y donde distinquen:
4.3 - A program that is correct in all other aspects,
operating on correct data, containing unspecified
behavior shall be a correct program and act in
accordance with 5.1.2.3.
4.5 - A strictly conforming program shall use only those
features of the language and library specified in this
International Standard. It shall not produce output
dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not
exceed any minimum implementation limit.
4.6 - Aqui distinquen entre implementaciones "hosted" y
"freestanding", ambas conformes con el estandar. Y ademas
indica (refiriendose a ambas):
"A conforming implementation may have extensions
(including additional library functions), provided
they do not alter the behavior of any strictly conforming
program."
4.7 A conforming program is one that is acceptable to
a conforming implementation.

Asi que segun tu ni siquiera deberiamos aceptar aqui cuestiones
conformes al "estandar internacional de C", si no solo aquellas
definidas como "estrictamente conformes".

No deja de resultarme sorprendente, que a estas alturas estemos
discutiendo sobre esto.
Post by Fernando Arbeiza
Y, como tú mismo has dicho, una variante de C es eso, una variante. Lo
puedes llamar GNU C, Turbo C o poniendo delante de la C lo que quieras.
Eso es lo que tu dices. Como ya he comentado la propia ISO define a su
estandar como "C programming language standard ISO/IEC 9899". Y en
ningun momento dice que otros estandares o versiones del lenguaje C no
son C.
Post by Fernando Arbeiza
Post by Martin J. Sanchez
Lo de cambiar el Followup-To, para que la conversacion siga en otro
grupo, es inaceptable (a no ser que uno sea el originador del thread)
y resalte la redireccion en el mensaje.
Si estás seguro de que pertenece a otro grupo, ¿por qué no? Si alguien
ha preguntado donde le ha dado la gana yo respondo donde quiero ;-)
Por que no tienes derecho a que mis respuestas puedan ir a un grupo al
que no tenia ninguna intencion en contestar, o del que no leo las
respuestas.
Post by Fernando Arbeiza
....
¿Y cuál es el problema? Utilizas es.comp.lenguajes.misc. Cuando el
tráfico crezca mucho, se creará es.comp.lenguajes.objetos; y cuando ya
haya suficiente tráfico, es.comp.lenguajes.objetos.corba. Me parece algo
bastante lógico.
Segun esta misma observacion (y segun las reglas de la jerarquia es.*)
es.comp.lenguajes.c deberia desaparecer y llevarse a uno de estos
grupos, por que en absoluto cumple la norma del numero de mensajes.
Te gusta la idea?
Post by Fernando Arbeiza
Post by Martin J. Sanchez
No pretendo dictar lo que es y no es off-topic en este grupo.
Simplemente es una opinion, basada en el uso que de
es.comp.lenguajes.c se ha estado haciendo durante años, y en su
RFD/RFV (actualmente parece no estar disponible). Todos nosotros y los
que vengan, deberiamos aclarar como queremos usar y que queremos que
sea este grupo.
Perfecto, en eso estoy completamente de acuerdo. Y creo que he dado mi
opinión. Por si acaso: Creo que en este grupo se debe discutir sobre C
(el estándar, su librería e incluso variantes). También podría
discutirse sobre el uso de librerías externas. Pero el resultado de una
llamada al sistema es objeto de discusión sólo para los que discutan
sobre ese sistema operativo,
Estas diciendo algo como: usa x, no preguntes "para que" y "por que",
por que aqui es off-topic.

De verdad, aqui no hay trafico alguno. Lo que se pretende es que sea un
grupo util. Para saber si algo es estandar o no, simplemente hay que
leer el estandar, y/o poner la opcion -pedantic (y no me refiero a ti
:-) ) o algo pareceido en las opciones de construccion.

Un saludo,
Martin.
Fernando Arbeiza
2003-09-22 21:52:00 UTC
Permalink
On Mon, 22 Sep 2003 21:28:46 +0200, Martin J. Sanchez
Post by Martin J. Sanchez
Como bien dices han existido y existen variaciones importantes en las
implementaciones de C, y como resultado han surgido distintos estandares
que intentan definir lo que encontraras en una implementacion de C
sujeta a uno de esos estandares, u otras peculiaridades (vease POSIX,
X-OPEN, etc).
No, como ya he dicho, ese es el problema. Creo que no se queda clara la
separación entre el C y, por ejemplo, POSIX. POSIX no es un estándar
de C. Es un estándar que define una interfaz con el sistema operativo.
Para definir la interfaz utiliza como base el C estándar, y describe su
uso utilizando el C, pero lo importante, lo que realizan las funciones
no tiene nada que ver con el C, sino con el sistema operativo que
funciona debajo (y que se tienen que comportar según POSIX especifica).

Además, creo que POSIX ha dejado claro que sería mejor no depender de
ningún lenguaje:

Language-Dependent Services for the C Programming Language

POSIX.1 is, for historical reasons, both a specification of an
operating system interface, shell and utilities, and a C binding for
that specification. Efforts had been previously undertaken to
generate a language-independent specification; however, that had
failed, and the fact that the ISO C standard is the de facto primary
language on POSIX and the UNIX system makes this a necessary and
workable situation.
Post by Martin J. Sanchez
Pero no existe el termino "C estandar", y ni siquiera un
unico estandar de C. Aunque como "C estandar" nos solemos referir a el
"estandar internacional del lenguaje C" de ISO/IEC, que es el "C
programming language standard ISO/IEC 9899" o al "ISO/IEC 9899:1990" con
las correcciones dadas en "ISO/IEC 9899/COR1:1994", ISO/IEC
9899/COR2:1995" y "ISO/IEC 9899/AMD1:1995.
¿Y cuántos estándares más de C hay? Me refiero a un intento de
normalizar el lenguaje, no a las extensiones que han incluido algunos
desarrolladores de compiladores (GNU C, Turbo C,...); ni a
implementaciones concretas del estándar.
Post by Martin J. Sanchez
"A conforming implementation may have extensions
(including additional library functions), provided
they do not alter the behavior of any strictly conforming
program."
4.7 A conforming program is one that is acceptable to
a conforming implementation.
Asi que segun tu ni siquiera deberiamos aceptar aqui cuestiones
conformes al "estandar internacional de C", si no solo aquellas
definidas como "estrictamente conformes".
No. Lo que creo es que aquí se debería discutir:
· Cuestiones "estrictamente conformes"
· Cuestiones "conformes" mientras se discuta sobre la parte
especificada en el estándar.
· Cuestiones "conformes" no especificadas en el estándar
(comportamiento no especificado, extensiones, librerías...), pero
siempre aclarando que por no estar especificado es un comportamiento
dependiente de la plataforma.

Pero nunca el resultado de una llamada al sistema operativo, repito,
pues pertenece a él (al sistema operativo); y las consecuencias de esa
llamada entran en el ámbito de discusión de los grupos de sistemas
operativos, no aquí.
Post by Martin J. Sanchez
No deja de resultarme sorprendente, que a estas alturas estemos
discutiendo sobre esto.
A mí no, pero más que nada porque considero que existe esa confusión
entre lo que es el lenguaje de programación y lo que son extensiones y
llamadas al sistema operativo.
Post by Martin J. Sanchez
Eso es lo que tu dices. Como ya he comentado la propia ISO define a su
estandar como "C programming language standard ISO/IEC 9899". Y en
ningun momento dice que otros estandares o versiones del lenguaje C no
son C.
El estándar también dice esto:

This International Standard specifies the form and establishes the
interpretation of programs written in the C programming language.

Según el 'Rationale' del estándar, el propio estándar es:

The Committee's overall goal was to develop a clear, consistent, and
unambiguous Standard for the C programming language which codifies
the common, existing definition of C and which promotes the
portability of user programs across C language environments.

Es decir, surge por la necesidad de normalizar el lenguaje; para que
cuando uno diga C sepamos a que se refiere. Es decir, yo considero que,
una vez aparecido un estándar internacionalmente aceptado que define el
lenguaje C, no cabe duda de a qué se refiere uno cuando habla del C.

Todo lo demás será una extensión, un dialecto, algo que se parece, pero
no C.
Post by Martin J. Sanchez
Post by Fernando Arbeiza
Si estás seguro de que pertenece a otro grupo, ¿por qué no? Si alguien
ha preguntado donde le ha dado la gana yo respondo donde quiero ;-)
Por que no tienes derecho a que mis respuestas puedan ir a un grupo al
que no tenia ninguna intencion en contestar, o del que no leo las
respuestas.
Bueno, el Followup-to es una indicación sobre a qué grupo debería ir la
respuesta; no una orden tajante. Además, creo que es de buena educación
avisar de que la respuesta puede que no vaya a ese grupo.
Post by Martin J. Sanchez
Segun esta misma observacion (y segun las reglas de la jerarquia es.*)
es.comp.lenguajes.c deberia desaparecer y llevarse a uno de estos
grupos, por que en absoluto cumple la norma del numero de mensajes.
Te gusta la idea?
No, gustarme no. Pero no se trata sólo de lo que te guste o no. Con el
tráfico que tienen es.comp.lenguajes.c, es.comp.lenguajes.c++ y
es.comp.lenguajes.misc consideraría lógico que los dos primeros
desaparecieran y se llevase todo en es.comp.lenguajes.misc. No creo que
fuese un gran inconveniente para nosotros (siempre se pueden marcar los
asuntos con el nombre del lenguaje). Y, quien sabe, quizá en algún
momento volviera a haber un grupo de c.
Post by Martin J. Sanchez
Post by Fernando Arbeiza
Perfecto, en eso estoy completamente de acuerdo. Y creo que he dado mi
opinión. Por si acaso: Creo que en este grupo se debe discutir sobre C
(el estándar, su librería e incluso variantes). También podría
discutirse sobre el uso de librerías externas. Pero el resultado de una
llamada al sistema es objeto de discusión sólo para los que discutan
sobre ese sistema operativo,
Estas diciendo algo como: usa x, no preguntes "para que" y "por que",
por que aqui es off-topic.
No, estoy diciendo algo como:

Eso no se puede hacer en C. Podrías utilizar X en el sistema Y. Pero
si quieres saber como funciona, mejor pregunta en un grupo del
sistema Y, que sabrán mejor como va.
Post by Martin J. Sanchez
De verdad, aqui no hay trafico alguno. Lo que se pretende es que sea un
grupo util. Para saber si algo es estandar o no, simplemente hay que
leer el estandar,
Bien, pero hay gente que no quiere leer, no puede leer, o ni siquiera
conoce el estándar. O que no sabe distinguir entre una función portable
del lenguaje y una función específica de su sistema operativo. Y como
creo que son bastantes, sigo pensando que hay (como mínimo) que
indicarlo.
Post by Martin J. Sanchez
y/o poner la opcion -pedantic (y no me refiero a ti :-) ) o algo
pareceido en las opciones de construccion.
Ya, seguro que no te refieres a mí ;-) No, en serio, si soy pedante (o
estricto, llámalo como quieras porque lo soy :-) en esto es porque creo
que es importante la distinción. No me cansaré de repetirlo, creo que
hay mucha confusión entre lo que es estándar y lo que no; y no está de
más recordarlo cada vez que aparece la ocasión.

Vuelvo a poner el mismo ejemplo, pero creo que las funciones getchar() y
getch() son el ejemplo perfecto. No sé cuanta gente sabe que getchar()
es estándar y getch() no lo es.

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Martin J. Sanchez
2003-09-23 09:58:49 UTC
Permalink
On Mon, 22 Sep 2003 23:52:00 +0200, Fernando Arbeiza
Post by Fernando Arbeiza
On Mon, 22 Sep 2003 21:28:46 +0200, Martin J. Sanchez
No, como ya he dicho, ese es el problema. Creo que no se queda clara la
separación entre el C y, por ejemplo, POSIX. POSIX no es un estándar
de C. Es un estándar que define una interfaz con el sistema operativo.
Para definir la interfaz utiliza como base el C estándar,
...
Segun tu definicion de C, es dificil, por que las primeras versiones
de POSIZ son muy anteriores a cualquier estandar ISO.
Post by Fernando Arbeiza
Language-Dependent Services for the C Programming Language
POSIX.1 is, for historical reasons, both a specification of an
operating system interface, shell and utilities, and a C binding for
that specification. Efforts had been previously undertaken to
generate a language-independent specification; however, that had
failed, and the fact that the ISO C standard is the de facto primary
language on POSIX and the UNIX system makes this a necessary and
workable situation.
Lo que indica que para un programador, sea un programador C o no, lo
importante es saber como hacer las cosas.
Post by Fernando Arbeiza
Post by Martin J. Sanchez
Asi que segun tu ni siquiera deberiamos aceptar aqui cuestiones
conformes al "estandar internacional de C", si no solo aquellas
definidas como "estrictamente conformes".
· Cuestiones "estrictamente conformes"
· Cuestiones "conformes" mientras se discuta sobre la parte
especificada en el estándar.
Eso seria estrictamente conforme.

Por otro lado, se te olvida decir que las aseveraciones de "no es
estandar", refiriendote a funciones no especificadas en el estandar,
no es correcta. Deberias decir no es estrictamente conforme, por que
conforme puede serlo.
Post by Fernando Arbeiza
· Cuestiones "conformes" no especificadas en el estándar
(comportamiento no especificado, extensiones, librerías...), pero
siempre aclarando que por no estar especificado es un comportamiento
dependiente de la plataforma.
Estas creando una nueva RFD del grupo?
Post by Fernando Arbeiza
Pero nunca el resultado de una llamada al sistema operativo, repito,
pues pertenece a él (al sistema operativo); y las consecuencias de esa
llamada entran en el ámbito de discusión de los grupos de sistemas
operativos, no aquí.
Sabes algo de sistemas operativos?

Quien te ha dicho que, por ejemplo, que el getuid() de POSIX sea una
abstraccion del sistema operativo X, puede ser una implementacion
especifica de POSIX, no proporcionada por el SO y si por una libreria.

Exactamente igual sucede con la utilizacion de muchas librerias o
facilidades. Si alguien pregunta algo sobre XML, OGL, LDAP, etc. les
rediriges a un grupo de sistemas operativos? Que tiene esto que ver
con SOs?

No estoy diciendo que aqui se discutan de forma sistematica temas no
estrictamente especificos de C. Pero tampoco me parece correcto
etiquetarlo con el off-topic.

Por otro lado, he participado en este grupo desde que se llamaba
es.foro.c.
Post by Fernando Arbeiza
Post by Martin J. Sanchez
No deja de resultarme sorprendente, que a estas alturas estemos
discutiendo sobre esto.
A mí no, pero más que nada porque considero que existe esa confusión
entre lo que es el lenguaje de programación y lo que son extensiones y
llamadas al sistema operativo.
Mientras sigas empeñado en discutir lo que a ti te parece C,
sequiremos confundiendo patatas con merluzas.
Post by Fernando Arbeiza
Post by Martin J. Sanchez
Eso es lo que tu dices. Como ya he comentado la propia ISO define a su
estandar como "C programming language standard ISO/IEC 9899". Y en
ningun momento dice que otros estandares o versiones del lenguaje C no
son C.
This International Standard specifies the form and establishes the
interpretation of programs written in the C programming language.
Siempre refiendose a implementaciones conformes con el estandar en
cuestion.
Post by Fernando Arbeiza
The Committee's overall goal was to develop a clear, consistent, and
unambiguous Standard for the C programming language which codifies
the common, existing definition of C and which promotes the
portability of user programs across C language environments.
Exacto. Desarrolla un estandar para un lenguaje. No es el autor del
lenguaje. Y ademas, se basa en la definicion actual (K&R) del mismo.
Post by Fernando Arbeiza
Es decir, surge por la necesidad de normalizar el lenguaje; para que
cuando uno diga C sepamos a que se refiere. Es decir, yo considero que,
una vez aparecido un estándar internacionalmente aceptado que define el
lenguaje C, no cabe duda de a qué se refiere uno cuando habla del C.
Si yo digo como se construye una casa y especifico los criterios y
normativas de construccion, tu podras cumplirlas o no, pero en ningun
caso podre decir que eso no es una casa.

Existen multitud de estandares para casi todo. La utilizacion o no de
un estandar puede o no ser mandatorio en una normativa.
Post by Fernando Arbeiza
Todo lo demás será una extensión, un dialecto, algo que se parece, pero
no C.
No hay remedio.

Por lo visto he estado usando durante muchos años el "lenguaje ...",
he participado en la creacion de varios compiladores del "lenguaje
..." (alguno archiconocido), pero ahora no se como se llamaba el
"lenguaje ...".
Post by Fernando Arbeiza
Post by Martin J. Sanchez
Post by Fernando Arbeiza
Si estás seguro de que pertenece a otro grupo, ¿por qué no? Si alguien
ha preguntado donde le ha dado la gana yo respondo donde quiero ;-)
Por que no tienes derecho a que mis respuestas puedan ir a un grupo al
que no tenia ninguna intencion en contestar, o del que no leo las
respuestas.
Bueno, el Followup-to es una indicación sobre a qué grupo debería ir la
respuesta; no una orden tajante. Además, creo que es de buena educación
avisar de que la respuesta puede que no vaya a ese grupo.
Perdon?
Followup-to es un campo que hace que nuestro lector de correo se
dirija alli cuando contestamos.

Y si, en efecto, es de buena educacion indicar el hecho, pero claro si
encimas pones el OT (cuya unica razon es poder el filtrado), la cosa
es bastante fea.
Post by Fernando Arbeiza
Post by Martin J. Sanchez
Segun esta misma observacion (y segun las reglas de la jerarquia es.*)
es.comp.lenguajes.c deberia desaparecer y llevarse a uno de estos
grupos, por que en absoluto cumple la norma del numero de mensajes.
Te gusta la idea?
No, gustarme no. Pero no se trata sólo de lo que te guste o no. Con el
tráfico que tienen es.comp.lenguajes.c, es.comp.lenguajes.c++ y
es.comp.lenguajes.misc consideraría lógico que los dos primeros
desaparecieran y se llevase todo en es.comp.lenguajes.misc. No creo que
fuese un gran inconveniente para nosotros (siempre se pueden marcar los
asuntos con el nombre del lenguaje). Y, quien sabe, quizá en algún
momento volviera a haber un grupo de c.
Estoy empezando a pensar que es lo mas adecuado.

De esta forma ninguna pregunta podria ser censurada con la etiqueta
off-topic. Aunque mejor no poner el nombre del lenguaje en el asunto,
no vaya a ser que te lo discutan ;-)

Un saludo,
Martin.
Fernando Arbeiza
2003-09-23 13:53:49 UTC
Permalink
On Tue, 23 Sep 2003 11:58:49 +0200, Martin J Sanchez
Post by Martin J. Sanchez
Segun tu definicion de C, es dificil, por que las primeras versiones
de POSIZ son muy anteriores a cualquier estandar ISO.
Hombre, todo evoluciona :-) Cuando existió el estándar ISO de C, los de
POSIX se adecuaron a él.
Post by Martin J. Sanchez
Lo que indica que para un programador, sea un programador C o no, lo
importante es saber como hacer las cosas.
Totalmente de acuerdo. De hecho, me parecería muy sospechoso alguien que
se llamase programador C. Un programador tiene que saber hacer las
cosas, y entonces elegir le herramienta que más se adecúe. ¿Crees que es
posible que haya algún programador que sólo sepa un lenguaje?
Post by Martin J. Sanchez
Post by Fernando Arbeiza
· Cuestiones "estrictamente conformes"
· Cuestiones "conformes" mientras se discuta sobre la parte
especificada en el estándar.
Eso seria estrictamente conforme.
Pues no, en cuanto un programa utiliza una sola característica que no es
"estrictamente conforme", ya no es un programa "estrictamente conforme".
Luego me refería a discutir la parte especificada en el estándar de
programas conformes.
Post by Martin J. Sanchez
Por otro lado, se te olvida decir que las aseveraciones de "no es
estandar", refiriendote a funciones no especificadas en el estandar,
no es correcta. Deberias decir no es estrictamente conforme, por que
conforme puede serlo.
Tampoco es así. Pongamos el ejemplo de la función system. Aparece
especificada en el estándar; sin embargo en cuanto la utilices con algo
que no sea un puntero NULL deja de ser un programa estrictamente
conforme.
Post by Martin J. Sanchez
Estas creando una nueva RFD del grupo?
Creo que quedo claro que era _mi_ opinión sobre lo que _debería_ ser la
RFD del grupo. Como no puedo acceder a la verdadera, no puedo
contrastarla.
Post by Martin J. Sanchez
Post by Fernando Arbeiza
Pero nunca el resultado de una llamada al sistema operativo, repito,
pues pertenece a él (al sistema operativo); y las consecuencias de esa
llamada entran en el ámbito de discusión de los grupos de sistemas
operativos, no aquí.
Sabes algo de sistemas operativos?
Quien te ha dicho que, por ejemplo, que el getuid() de POSIX sea una
abstraccion del sistema operativo X, puede ser una implementacion
especifica de POSIX, no proporcionada por el SO y si por una libreria.
¿Sabes algo de inglés?

Portable Operating System Interface
[POSIX] consists of both operating system interfaces and shell and
utilities ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Que el sistema operativo no tenga una capacidad y tenga que emularla
mediante una librería no quita para que el POSIX esté concebido como lo
está.
Post by Martin J. Sanchez
Exactamente igual sucede con la utilizacion de muchas librerias o
facilidades. Si alguien pregunta algo sobre XML, OGL, LDAP, etc. les
rediriges a un grupo de sistemas operativos? Que tiene esto que ver
con SOs?
Post by Fernando Arbeiza
No. Lo que creo es que aquí se debería discutir: [...]
· Cuestiones "conformes" no especificadas en el estándar
(comportamiento no especificado, extensiones, librerías...), pero
siempre aclarando que por no estar especificado es un comportamiento
dependiente de la plataforma.
Y creo que ahí incluía ya los comportamientos no especificados por el
estándar, las extensiones y las librerías. No me recortes lo que ya he
dicho ;-)
Post by Martin J. Sanchez
Post by Fernando Arbeiza
A mí no, pero más que nada porque considero que existe esa confusión
entre lo que es el lenguaje de programación y lo que son extensiones y
llamadas al sistema operativo.
Mientras sigas empeñado en discutir lo que a ti te parece C,
sequiremos confundiendo patatas con merluzas.
No, lo que a mí me parece C; sino lo que creo que debe discutirse en un
grupo del lenguaje C y lo que debe discutirse en un grupo de sistemas
operativos.
Post by Martin J. Sanchez
Post by Fernando Arbeiza
This International Standard specifies the form and establishes the
interpretation of programs written in the C programming language.
Siempre refiendose a implementaciones conformes con el estandar en
cuestion.
Hombre, es que el estándar sólo puede especificar implementaciones
conformes con el estándar. (Trabalenguas al canto)
Post by Martin J. Sanchez
Exacto. Desarrolla un estandar para un lenguaje. No es el autor del
lenguaje. Y ademas, se basa en la definicion actual (K&R) del mismo.
Hombre, ya veo el problema. ¿Consideras la definición actual la que
hicieron K&R antes del estándar? Hasta ellos (K&R) consideran la
definición de C como la que propone el estándar. Creo que en el "The C
Programming Language" 2ª edición ellor (K&R) lo dejaron claro. Por
ejemplo:

The first printing of the book [The C programming language] was made
before the Standard was finalized; these copies say "Based on
Draft-Proposed ANSI C" on the front cover. All subsequent printings
are identified by a large red ``ANSI C'' on the right center of the
cover.
Post by Martin J. Sanchez
Si yo digo como se construye una casa y especifico los criterios y
normativas de construccion, tu podras cumplirlas o no, pero en ningun
caso podre decir que eso no es una casa.
Existen multitud de estandares para casi todo. La utilizacion o no de
un estandar puede o no ser mandatorio en una normativa.
Creo que nos estamos dispersando. Pongamos un ejemplo, tenemos un
estándar que define el protocolo IP. Pues bien, tu puedes coger y
decidir no cumplir el estándar. ¿Crees que a eso se le puede llamar IP?
Imaginamos que puedes y lo llamas IP, FIP o lo que sea. Que no es IP lo
vas a saber en cuanto te intentes conectar a alguna red IP.

Por lo mismo, ¿crees que se puede llamar C a lo que no cumple el
estándar? Si eso se hace, cuando vas a compilar es cuando surgen las
sorpresas. Normalmente, si defines extensiones o algo que se parece no
lo llamaras C (sino GNU C, Turbo C, Fernando C o lo que quieras).
Post by Martin J. Sanchez
Post by Fernando Arbeiza
Bueno, el Followup-to es una indicación sobre a qué grupo debería ir la
respuesta; no una orden tajante. Además, creo que es de buena educación
avisar de que la respuesta puede que no vaya a ese grupo.
Perdon?
Followup-to es un campo que hace que nuestro lector de correo se
dirija alli cuando contestamos.
¿Mande? Followup-to es un campo que indica que se desea que las
respuestas se dirijan allí. Pero el que contesta puede decidir si hace
caso al Followup-to o no. Por lo menos mi lector de noticias me lo
permite.
Post by Martin J. Sanchez
Y si, en efecto, es de buena educacion indicar el hecho, pero claro si
encimas pones el OT (cuya unica razon es poder el filtrado), la cosa
es bastante fea.
De esta forma ninguna pregunta podria ser censurada con la etiqueta
off-topic. Aunque mejor no poner el nombre del lenguaje en el asunto,
no vaya a ser que te lo discutan ;-)
La cosa es que no pienso que la etiqueta OT sea algo feo o una forma de
censura. Pero yo lo veo como una indicación de que en otro grupo te
pueden ayudar mejor. Aunque también se utiliza cuando el que pregunta ha
fallado el grupo por tres pueblos.

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Martin J. Sanchez
2003-09-23 15:42:38 UTC
Permalink
On Tue, 23 Sep 2003 15:53:49 +0200, Fernando Arbeiza
Post by Fernando Arbeiza
On Tue, 23 Sep 2003 11:58:49 +0200, Martin J Sanchez
No me voy a extender mas por que parece que la conversacion se esta
volviendo obtusa.
Post by Fernando Arbeiza
. Cuestiones "estrictamente conformes"
ok.
Post by Fernando Arbeiza
· Cuestiones "conformes" mientras se discuta sobre
la parte especificada en el estándar.
Que es practicamente lo mismo que decir "solo se discute lo
estrictamente conforme" (si ya he leido lo del NULL en la llamada a
system).
Post by Fernando Arbeiza
· Cuestiones "conformes" no especificadas en el estándar
(comportamiento no especificado, extensiones, librerías...), pero
siempre aclarando que por no estar especificado es un
comportamiento dependiente de la plataforma.
Evidentemente esto se me paso por alto, por que es lo que yo he estado
demandando. Sin embargo parece que aqui dices lo contrario a lo que te
he entendido hasta ahora.

Por otro lado, en mi discusion sobre otros estandares intentaba
puntualizar cosas como esta que dices en el anterior parrafo:
"siempre aclarando que por no estar especificado es un
comportamiento dependiente de la plataforma."
Por ejemplo POSIX expone claramente que se debe esperar de un sistema
que implemente un interface que cumpla tal estandar, con lo que el
hecho de que no este definido en el estandar de C, no indica que su
comportamiento sea dependiente de plataforma.
Post by Fernando Arbeiza
Pero nunca el resultado de una llamada al sistema operativo, repito,
pues pertenece a él (al sistema operativo); y las consecuencias de esa
llamada entran en el ámbito de discusión de los grupos de sistemas
operativos, no aquí.
Si p.ej. estoy realizando un programa cualquiera en C que requiere un
manejo de memoria muy eficaz (o especializado), necesitare conocer la
forma en como la implementacion de la libreria usa la memoria en el SO
en concreto, de que alternativas estandar o no dispongo, o que se
puede hacer para, conservando la conformidad (en lo posible) con el
lenguaje, aprovechar los recursos del S.O. en cuestion para solucionar
el problema.

Existen problematicas diversas: como hacer tal cosa en el SO X?,
donde seguramente es mejor dirigirse a un grupo especializado en el SO
X; O como hacer tal cosa, usando C, en el SO X?, donde este grupo
puede (o no) ser adecuado; o incluso como llamo desde C a una funcion
en una DLL del SO x?, y donde tambien este grupo puede ser adecuado;
etc.

En el caso del getch() que pones de ejemplo, es evidente que no esta
definida en la libreria estandar y que hay que hacerlo notar, pero me
parece de una ayuda superior el mencionar o bien las alternativas, o
aportar la definicion de getch para obtener el comportamiento deseado
en un sistema dado, en lugar de decir: "esto no se puede hacer en C" o
"esto es off-topic por que no es C". Que es mas pedagogico? Que es mas
util?

Mi planteamiento es que no se puede ser tajante. C esta siendo
relegado por otros lenguajes, pero se sigue utilizando en proyectos
muy diversos: drivers, SOs, microcontroladores, etc. Su utilizacion es
muy importante en entornos donde, casualmente, es practicamente
imposible realizar programas estrictamente conformes. Asi que para mi
el objeto del grupo no es otro que un sitio donde intercambiar ideas,
experiencias y ayuda con programadores que usan C en sus propositos.

Un saludo,
Martin.
Fernando Arbeiza
2003-09-23 16:09:00 UTC
Permalink
On Tue, 23 Sep 2003 17:42:38 +0200, Martin J Sanchez
Post by Martin J. Sanchez
No me voy a extender mas por que parece que la conversacion se esta
volviendo obtusa.
Pues sí, creo que aquí lo dejamos ;-)
Post by Martin J. Sanchez
Post by Fernando Arbeiza
. Cuestiones "estrictamente conformes"
ok.
Post by Fernando Arbeiza
· Cuestiones "conformes" mientras se discuta sobre
la parte especificada en el estándar.
Que es practicamente lo mismo que decir "solo se discute lo
estrictamente conforme" (si ya he leido lo del NULL en la llamada a
system).
Post by Fernando Arbeiza
· Cuestiones "conformes" no especificadas en el estándar
(comportamiento no especificado, extensiones, librerías...), pero
siempre aclarando que por no estar especificado es un
comportamiento dependiente de la plataforma.
Evidentemente esto se me paso por alto, por que es lo que yo he estado
demandando. Sin embargo parece que aqui dices lo contrario a lo que te
he entendido hasta ahora.
Si es así, lo siento, porque no he sabido hacerme entender. He intentado
decir que cuando pasen de ser lo que he nombrado arriba a llamadas al
sistema operativo, nadie mejor que los de un grupo de noticias de ese
sistema para saber qué efectos tiene. ¿Seguro que no lo he dicho? :-)
Post by Martin J. Sanchez
Por otro lado, en mi discusion sobre otros estandares intentaba
"siempre aclarando que por no estar especificado es un
comportamiento dependiente de la plataforma."
Por ejemplo POSIX expone claramente que se debe esperar de un sistema
que implemente un interface que cumpla tal estandar, con lo que el
hecho de que no este definido en el estandar de C, no indica que su
comportamiento sea dependiente de plataforma.
Pues hombre, es dependiente de que la plataforma implemente el interfaz
POSIX.
Post by Martin J. Sanchez
En el caso del getch() que pones de ejemplo, es evidente que no esta
definida en la libreria estandar y que hay que hacerlo notar, pero me
parece de una ayuda superior el mencionar o bien las alternativas, o
aportar la definicion de getch para obtener el comportamiento deseado
en un sistema dado, en lugar de decir: "esto no se puede hacer en C" o
"esto es off-topic por que no es C". Que es mas pedagogico? Que es mas
util?
Es que yo creo que hay que hacer las dos cosas. La ayuda y después decir
que no se puede hacer con C.

Bueno, creo que esto no da para más.

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Bartomeu
2003-09-23 12:35:49 UTC
Permalink
Post by Fernando Arbeiza
On Mon, 22 Sep 2003 21:28:46 +0200, Martin J. Sanchez
Post by Martin J. Sanchez
[...]
Pero no existe el termino "C estandar", y ni siquiera un
unico estandar de C. Aunque como "C estandar" nos solemos referir a
el "estandar internacional del lenguaje C" de ISO/IEC, que es el "C
programming language standard ISO/IEC 9899" o al "ISO/IEC
9899:1990" con las correcciones dadas en "ISO/IEC 9899/COR1:1994",
ISO/IEC 9899/COR2:1995" y "ISO/IEC 9899/AMD1:1995.
[...]
Vuelvo a poner el mismo ejemplo, pero creo que las funciones
getchar() y getch() son el ejemplo perfecto. No sé cuanta gente sabe
que getchar() es estándar y getch() no lo es.
El 'C estandar' es el estandar, pero creo que no hay que ser tan estricto, y
más cuando el estandar tiene una incongruencia tan grande como que una
función que se llama getchar() devuelve un int en vez de un char, que sería
lo lógico. ;-))

¿qué dirias del programador que definiera una función como esta?
tipoa get_tipob(void);
Como mínimo está confundiendo los tipos y a la larga, cuando no tenga la
función fresca en la memoria, cometerá errores, o hará que otros los
cometan. No es una buena manera de programar.

Por lo tanto, creo que si alguien pregunta algo que no es del estandar, o no
le respondes, o se le piden más datos, o se le contesta. Pero no me parece
correcto enviarlo a otro sitio, y más si sabes la respuesta. Dale una
respuesta y añade una coletilla: '.. pero esto no es estandar' o '... y si
vas a tal.grupo.de.noticias te darán más datos'. Así todos podremos aprender
cosas de otros SO sin tener que suscribirnos a más grupos de los que podemos
abarcar, y este grupo seguirá vivo.
Post by Fernando Arbeiza
Un saludo.
--
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Fernando Arbeiza
2003-09-23 14:00:09 UTC
Permalink
Post by Bartomeu
Post by Fernando Arbeiza
Vuelvo a poner el mismo ejemplo, pero creo que las funciones
getchar() y getch() son el ejemplo perfecto. No sé cuanta gente sabe
que getchar() es estándar y getch() no lo es.
El 'C estandar' es el estandar, pero creo que no hay que ser tan estricto, y
más cuando el estandar tiene una incongruencia tan grande como que una
función que se llama getchar() devuelve un int en vez de un char, que sería
lo lógico. ;-))
¿Ein? ¿Y como detectas un EOF si devolviese un char?

Además, no es tanta incongruencia si piensas que los literales carácter
'\0' por ejemplo, tienen tipo int.
Post by Bartomeu
Por lo tanto, creo que si alguien pregunta algo que no es del estandar, o no
le respondes, o se le piden más datos, o se le contesta. Pero no me parece
correcto enviarlo a otro sitio, y más si sabes la respuesta. Dale una
respuesta y añade una coletilla: '.. pero esto no es estandar' o '... y si
vas a tal.grupo.de.noticias te darán más datos'. Así todos podremos aprender
cosas de otros SO sin tener que suscribirnos a más grupos de los que podemos
abarcar, y este grupo seguirá vivo.
Creo que me estoy repitiendo demasiado (seguro que no me explico bien,
en serio, a veces puedo ser muy obtuso). Pero creo que he dicho algo
parecido. Está bien dar la respuesta con coletilla, pero para detalles
del comportamiento en el grupo del S.O.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Bartomeu
2003-09-23 14:49:51 UTC
Permalink
Post by Fernando Arbeiza
Post by Bartomeu
Post by Fernando Arbeiza
Vuelvo a poner el mismo ejemplo, pero creo que las funciones
getchar() y getch() son el ejemplo perfecto. No sé cuanta gente
sabe que getchar() es estándar y getch() no lo es.
El 'C estandar' es el estandar, pero creo que no hay que ser tan
estricto, y más cuando el estandar tiene una incongruencia tan
grande como que una función que se llama getchar() devuelve un int
en vez de un char, que sería lo lógico. ;-))
¿Ein? ¿Y como detectas un EOF si devolviese un char?
Es lo que digo.
La función getchar está mal definida en el estandar. Es incongruente que una
función devuelva valores de dos tipos diferentes: EOF y char, y este tipo de
definiciones abundan en el estandar. Si hubieran diseñado de manera más
lógica las funciones, habrían definido así la función getchar:
int getchar(char *c);
La función devuelve un código de error como retorno (el int) y devuelve el
valor al puntero que le pasamos como argumento.

No es conveniente utilizar un retorno para dos cosas simultaneas y
excluyentes. No es una buena práctica de programación. El C abusa de este
método de devolver errores mezclados con resultados. Vale que esa definición
de las funciones permite crear código muy compacto y criptico, pero no
fomenta la buena programación y es una fuente constante de errores para los
principiantes y no tan principiantes.
Post by Fernando Arbeiza
Además, no es tanta incongruencia si piensas que los literales
carácter '\0' por ejemplo, tienen tipo int.
Otra incongruencia. Si es char tiene que ser char, y si es int tiene que ser
int. Si 'a' es un char y '\0x61' es (supongo) un char por qué '\0' tiene que
ser un int. Si quieres un int cero escribe directamente 0 sin comillas.
Un tipo con sizeof menor o igual a otro se podrían copiar: Todos los char se
podrían asignar a un int, pero en caso contrario no y en general
sizeof(char)<sizeof(int) por lo tanto no se debería poder asignar un int a
un char sin conversión explicita por parte del programador, que se supone
que sabe lo que hace.
Fernando Arbeiza
2003-09-23 15:28:32 UTC
Permalink
Post by Bartomeu
Post by Fernando Arbeiza
¿Ein? ¿Y como detectas un EOF si devolviese un char?
Es lo que digo.
La función getchar está mal definida en el estandar. Es incongruente que una
función devuelva valores de dos tipos diferentes: EOF y char, y este tipo de
definiciones abundan en el estandar. Si hubieran diseñado de manera más
int getchar(char *c);
La función devuelve un código de error como retorno (el int) y devuelve el
valor al puntero que le pasamos como argumento.
Pues quizá tengas razón. Puede ser que ya me haya acostumbrado a ello y
no me parezca raro. Y en C encuentro tantos sitios por donde puede
reventar la cosa que esto ya me parece de lo más normal ;-)

De todas formas, creo que mejor no discutir el prototipo de esas
funciones, porque estas funciones suelen ser así por motivos históricos
y a ver quien las cambia ahora.
Post by Bartomeu
No es conveniente utilizar un retorno para dos cosas simultaneas y
excluyentes. No es una buena práctica de programación. El C abusa de este
método de devolver errores mezclados con resultados. Vale que esa definición
de las funciones permite crear código muy compacto y criptico, pero no
fomenta la buena programación y es una fuente constante de errores para los
principiantes y no tan principiantes.
Tienes razón, pero el C no es precisamente un lenguaje que fomente la
buena programación. Como no tengas algo de disciplina el código puede
ser un churro ilegible.
Post by Bartomeu
Otra incongruencia. Si es char tiene que ser char, y si es int tiene que ser
int. Si 'a' es un char y '\0x61' es (supongo) un char
'a' es un int y '\0x61' es otro int; al igual que '\0'
Post by Bartomeu
por qué '\0' tiene que
ser un int. Si quieres un int cero escribe directamente 0 sin comillas.
Un tipo con sizeof menor o igual a otro se podrían copiar: Todos los char se
podrían asignar a un int, pero en caso contrario no y en general
sizeof(char)<sizeof(int) por lo tanto no se debería poder asignar un int a
un char sin conversión explicita por parte del programador, que se supone
que sabe lo que hace.
Ya, pero si quieres conversiones explícitas creo que el C no te va a
gustar ;-) Ahora en serio, creo que una parte que debe entenderse bien
en el C es la conversión implícita. Para ello hay tablas en los libros,
y el estándar lo especifica bastante. Puede que no guste, pero habrá que
vivir con ello. Si no puedes, prueba el ADA (por ejemplo), creo que te
gustará.

Siguiendo con getchar y los literales, en ese caso la conversión de ese
entero a un char (menos con EOF) no dará problemas, pues por definición
estarán dentro del rango de los char.

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Bartomeu
2003-09-23 16:51:59 UTC
Permalink
Post by Fernando Arbeiza
Post by Bartomeu
Post by Fernando Arbeiza
¿Ein? ¿Y como detectas un EOF si devolviese un char?
Es lo que digo.
La función getchar está mal definida en el estandar. Es
incongruente que una función devuelva valores de dos tipos
diferentes: EOF y char, y este tipo de definiciones abundan en el
estandar. Si hubieran diseñado de manera más lógica las funciones,
int getchar(char *c);
La función devuelve un código de error como retorno (el int) y
devuelve el valor al puntero que le pasamos como argumento.
Pues quizá tengas razón. Puede ser que ya me haya acostumbrado a
ello y no me parezca raro. Y en C encuentro tantos sitios por donde
puede reventar la cosa que esto ya me parece de lo más normal ;-)
De todas formas, creo que mejor no discutir el prototipo de esas
funciones, porque estas funciones suelen ser así por motivos
históricos y a ver quien las cambia ahora.
Pues nosotros. !Con un par de co*****!.... ¡¡¡Definamos el 'D'!!! :-))
!Tiremos todo el código existente a la papelera!
Post by Fernando Arbeiza
Post by Bartomeu
No es conveniente utilizar un retorno para dos cosas simultaneas y
excluyentes. No es una buena práctica de programación. El C abusa
de este método de devolver errores mezclados con resultados. Vale
que esa definición de las funciones permite crear código muy
compacto y criptico, pero no fomenta la buena programación y es una
fuente constante de errores para los principiantes y no tan
principiantes.
Tienes razón, pero el C no es precisamente un lenguaje que fomente la
buena programación. Como no tengas algo de disciplina el código puede
ser un churro ilegible.
Post by Bartomeu
Otra incongruencia. Si es char tiene que ser char, y si es int
tiene que ser int. Si 'a' es un char y '\0x61' es (supongo) un char
'a' es un int y '\0x61' es otro int; al igual que '\0'
Post by Bartomeu
por qué '\0' tiene que
ser un int. Si quieres un int cero escribe directamente 0 sin comillas.
Un tipo con sizeof menor o igual a otro se podrían copiar: Todos
los char se podrían asignar a un int, pero en caso contrario no y
en general sizeof(char)<sizeof(int) por lo tanto no se debería
poder asignar un int a un char sin conversión explicita por parte
del programador, que se supone que sabe lo que hace.
Ya, pero si quieres conversiones explícitas creo que el C no te va a
gustar ;-) Ahora en serio, creo que una parte que debe entenderse
bien en el C es la conversión implícita. Para ello hay tablas en los
libros, y el estándar lo especifica bastante. Puede que no guste,
pero habrá que vivir con ello. Si no puedes, prueba el ADA (por
ejemplo), creo que te gustará.
Ya leí el manual de ADA hace años. Me gustó. Pero por aquel entonces, hace
unos quince años, no pude acceder a un compilador y lo dejé correr.
Post by Fernando Arbeiza
Siguiendo con getchar y los literales, en ese caso la conversión de
ese entero a un char (menos con EOF) no dará problemas, pues por
definición estarán dentro del rango de los char.
Un saludo.
--
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Martin J. Sanchez
2003-09-23 20:45:51 UTC
Permalink
Fernando Arbeiza escribió en mensaje ...
Post by Fernando Arbeiza
...
¿Ein? ¿Y como detectas un EOF si devolviese un char?
Además, no es tanta incongruencia si piensas que los literales carácter
'\0' por ejemplo, tienen tipo int.
Solo puntualizar esto.

A efectos de evaluacion de expresiones los char estan sujetos a la
'integer promotion'.

Todos los caracteres basicos, ocupan un byte (3.4, 3.5 del estandar). Un
caracter nul es un byte con todos los bits a 0 (5.2.1.2).

Un char puede ser tratado (al ser promocinado en una expresion) como un
'signed int' o como un 'unsigned int' (5.2.4.2.1.1 y 6.2.5.15).

Un literal de caracter es de tipo int al ser evaluado, pero su valor es
el mismo que el resultado de promocionar un char (un byte) a int
(6.4.4.4, 5.1.1.2.5, 5.1.2.3 y 6.7.8).

Todo esto olvidandonos de los wchar_t.

Un saludo,
Martin.

znôrt
2003-09-23 07:42:50 UTC
Permalink
On Mon, 22 Sep 2003 19:23:47 +0200, Fernando Arbeiza
Post by Fernando Arbeiza
Y es que los sockets no tienen nada que ver con el C. Los procesos no
tienen nada que ver con el C. Los threads no tienen nada que ver con el
C. Son soluciones del sistema operativo a varios problemas, y que se
utilicen desde C es irrelevante. Se podía discutir la interfaz (devuelve
un entero, toma una estructura...), pero el comportamiento y el efecto
de esas funciones (crear un proceso, un thread o un socket...) es un
problema del sistema operativo, no de C. ¿Y en qué mejor sitio conocen
el comportamiento del sistema operativo que en un grupo donde se discute
ese sistema en concreto?
A mí me encanta poner ejemplos chorras, así que ahí va uno (muy, muy
- ¿Qué pasa si le pongo un volante verde a mi Simca 1000?
- ¿Y a mí que me importa? Pregunta en es.coches.tartanas que es
donde sabrán decirte.
- Ah, es que como mis manos manejan el volante y mis manos
pertenecen al cuerpo humano...
Muy, muy chorras ;-P
Eso me sugiere el chiste ese de cuántos ingenieros de software hacen
falta para cambiar una bombilla: ninguno, es un problema de hardware.
Pos nos quedamos a oscuras :D

Que los sockets no tienen nada que ver con la especificación de C es
evidente. Aun así son algo que desde C se puede y suele usar, y
debatir o enseñar cómo hacerlo creo quel tiene cabida perfectamente en
la temática. Yo también pienso que si nos ceñimos a hablar
estrictamente de C puro, hablaremos de bien poca cosa.

Imaginad a alguien que lleva media vida programando en Delphi (por
decir algo) y se inicia en C, se pone a usar sockets y no se aclara
con cómo están definidas las estructuras. Le mandaremos al grupo de
su sistema operativo? Es un opción. La otra es desarrollar un poquito
el tema, sin entrar en demasiados detalles del S.O. pero sí ubicando C
en un contexto un poquito más amplio, que en resumidas cuentas es lo
que interesa.

En rigor, todos tenéis vuestra razón. Yo creo que un cierto nivel de
OT enriquece la discusión y no me molesta en absoluto. Es cuestión de
no abusar. Y, por supuesto, no se puede usar el mismo rasero para la
jerarquía ecol*, cualquiera de cuyos grupos puede tener más mensajes
en un solo día que es.comp.lenguajes.c y c++ juntos en todo un año.
:-)

saludos
znôrt
Fernando Arbeiza
2003-09-23 11:36:50 UTC
Permalink
Post by znôrt
Que los sockets no tienen nada que ver con la especificación de C es
evidente. Aun así son algo que desde C se puede y suele usar, y
debatir o enseñar cómo hacerlo creo quel tiene cabida perfectamente en
la temática. Yo también pienso que si nos ceñimos a hablar
estrictamente de C puro, hablaremos de bien poca cosa.
Imaginad a alguien que lleva media vida programando en Delphi (por
decir algo) y se inicia en C, se pone a usar sockets y no se aclara
con cómo están definidas las estructuras. Le mandaremos al grupo de
su sistema operativo? Es un opción. La otra es desarrollar un poquito
el tema, sin entrar en demasiados detalles del S.O. pero sí ubicando C
en un contexto un poquito más amplio, que en resumidas cuentas es lo
que interesa.
Pues sí, estoy completamente de acuerdo contigo. Creo que aquí se podría
indicarle y orientarle un poco. Pero cuando necesite detalles del
funcionamiento creo que el grupo del S.O. es más adecuado. Y mis razones
no son el no querer discutir sobre ello, porque seguramente estaré
también en el grupo del S.O.; sino que mis razones son otras. Las vuelvo
a resumir, por si acaso ;-):

· Educativa. Que quede clara la frontera entre uno y otro.
· Práctica. Quien mejor pueda conocer el comportamiento de una
característica de un S.O. estará en el grupo del S.O.

Un saludo.
--
Fernando Arbeiza <URL: mailto:***@ono.com>
Crea tu propio Linux: <URL: http://www.escomposlinux.org/lfs-es>
Julián Albo
2003-09-23 15:55:17 UTC
Permalink
Post by znôrt
Que los sockets no tienen nada que ver con la especificación de C es
evidente. Aun así son algo que desde C se puede y suele usar, y
debatir o enseñar cómo hacerlo creo quel tiene cabida perfectamente en
la temática. Yo también pienso que si nos ceñimos a hablar
estrictamente de C puro, hablaremos de bien poca cosa.
Y si no, hablaremos de demasiadas.
Post by znôrt
Imaginad a alguien que lleva media vida programando en Delphi (por
decir algo) y se inicia en C, se pone a usar sockets y no se aclara
con cómo están definidas las estructuras. Le mandaremos al grupo de
su sistema operativo?
Le diremos que si le iba bien con Delphi ¿para qué quiere cambiar? ;)
Post by znôrt
Es un opción. La otra es desarrollar un poquito el tema, sin entrar en demasiados
detalles del S.O. pero sí ubicando C en un contexto un poquito más amplio, que en
¿Qué detalles tienen los sockets que no sean dependientes del sistema
operativo?
Post by znôrt
En rigor, todos tenéis vuestra razón. Yo creo que un cierto nivel de
OT enriquece la discusión y no me molesta en absoluto. Es cuestión de
no abusar.
Ya, pero es que si empezara a resolver aquí cualquier duda de windows,
por poner un ejemplo, la gente abusaría, no me cabe la menor duda.

Salu2
J.A. Gutierrez
2003-09-23 07:14:38 UTC
Permalink
Martin J. Sanchez <***@cin.es___> wrote:
: On Mon, 22 Sep 2003 12:32:45 +0200, Fernando Arbeiza
: <***@ono.com> wrote:

:>Hola:
:>.....
:>
:>¿Por cierto, hay alguna función POSIX que permita hacerlo? Porque he
:>estado buscando y no la encuentro. Ya, ya, está fuera de lugar, pero
:>aprovechando... ;-)
:>

: Sigo pensando que este tipo de preguntas no son off-topic, por mucho
: que algunos os empeñeis. El objeto de este grupo nunca ha sido
: discutir unicamente la libreria estandar de C.
: Si alguien pregunta: "como hago X en C?, le dirigis a grupos como
: es.comp.windows.programacion o es.comp.linux.programacion cuando alli

Pues en mi opinion, si que hay que redirigir a la gente a
esos grupos.
Simplemente, por que la respuesta es especifica del sistema
operativo o de las librerias de que se disponga.

p.e. en el caso que nos ocupa, otra respuesta valida podria
haber sido SetDateTime() (del ToolBox de MacOS clasico); entonces,
que hay que hacer, dar todas las respuestas posibles, ya que
el que pregunta ni siquiera se molesta en decir para que sistema
lo quiere? (o quizas, ni siquiera sabe que depende del sistema,
con lo que, aun hay mas razon para informarle).


Si no, la proxima vez que alguien pregunte, p.e.
"Como se hace un 'hello world' en C" ?
la respuesta podra ser perfectamente:

- hello.c -----------------------------------------------------------------
#include <Xm/XmAll.h>

void main(int argc, char *argv[])
{
Widget toplevel, main_w, button;
XtAppContext app;

XtSetLanguageProc(NULL, NULL, NULL);

toplevel = XtVaAppInitialize(&app, "main", NULL, 0,
&argc, argv, NULL, NULL);

main_w = XtVaCreateManagedWidget("main_w", xmMainWindowWidgetClass,
toplevel, XmNscrollingPolicy,
XmAUTOMATIC, NULL);

button = XtVaCreateWidget("Hello World", xmLabelWidgetClass, main_w, NULL);

XtManageChild(button);
XtRealizeWidget(toplevel);
XtAppMainLoop(app);

}
---------------------------------------------------------------------------

lo que no creo que sea particularmente util, y ademas a mucha
gente le parecera puro ruido en este grupo.



O tambien, el tipico caso en el que se da una respuesta dando
por supuesto que el que pregunta tiene el "S.O. Omnipresente (tm)"
y luego nos quejamos de que la gente escribe codigo no portable
y que se creen que no existe nada mas.




Asi que, si, sigo pensando que es importante diferenciar entre
aspectos (muy) dependientes del sistema operativo y aspectos
puramente relacionados con el lenguaje C.

: es tan offtopic como aqui (alli, como aqui, siempre habra quien piense
: que aquel no es un grupo especifico de C).

En un grupo *.programacion (donde * no es un lenguaje), por lo
general, nadie se queja de que la gente pregunte detalles de
una llamada al sistema "*" en un lenguaje en concreto...
--
finger ***@shiva.cps.unizar.es for PGP /
.mailcap tip of the day: / La vida es una carcel
application/ms-tnef; cat '%s' > /dev/null / con las puertas abiertas
text/x-vcard; cat '%s' > /dev/null / (A. Calamaro)
Martin J. Sanchez
2003-09-23 09:09:31 UTC
Permalink
On Tue, 23 Sep 2003 07:14:38 +0000 (UTC), "J.A. Gutierrez"
Post by J.A. Gutierrez
: Sigo pensando que este tipo de preguntas no son off-topic, por mucho
: que algunos os empeñeis. El objeto de este grupo nunca ha sido
: discutir unicamente la libreria estandar de C.
: Si alguien pregunta: "como hago X en C?, le dirigis a grupos como
: es.comp.windows.programacion o es.comp.linux.programacion cuando alli
Pues en mi opinion, si que hay que redirigir a la gente a
esos grupos.
Simplemente, por que la respuesta es especifica del sistema
operativo o de las librerias de que se disponga.
Repito que si existe un grupo especifico es logico darlo.
Pero tampoco creo que aqui sean off-topic muchas de las preguntas
planteadas. Nada mas.
Post by J.A. Gutierrez
p.e. en el caso que nos ocupa, otra respuesta valida podria
haber sido SetDateTime() (del ToolBox de MacOS clasico); entonces,
que hay que hacer, dar todas las respuestas posibles, ya que
el que pregunta ni siquiera se molesta en decir para que sistema
lo quiere? (o quizas, ni siquiera sabe que depende del sistema,
con lo que, aun hay mas razon para informarle).
Y se le debe informar. Pero decir que el uso de tal funcion, por el
mero hecho de no ser de la libreria del estandar ISO, no es C, es otra
cosa.
Post by J.A. Gutierrez
Si no, la proxima vez que alguien pregunte, p.e.
"Como se hace un 'hello world' en C" ?
- hello.c -----------------------------------------------------------------
#include <Xm/XmAll.h>
Ok. Para mi tu respuesta seria totalmente valida :-)


Un saludo,
Martin.
Loading...