🚀 go-pugleaf

Guillermo Rodriguez Garcia wrote:
> 
> El d�a Tue, 19 Jan 1999 23:44:36 +0100, Jonathan Revusky
> <jrevusky@jet.es> escribi�:
> 
> >> Qu� gracioso, eso de medir la portabilidad de un lenguaje en funci�n
> >> de lo que ocurre cuando escribes c�digo que realiza acciones ilegales.
> >
> >No veo porque es gracioso. El mismo programa produce el mismo
> >comportamiento en distintas plataformas. Punto. Es una definici�n muy
> >l�gica de portabilidad.
> 
> Un programa *legal* en C ANSI tambi�n produce el mismo comportamiento
> en distintas plataformas.

La verdad es que no me consta que escribir a una direcci�n inv�lida de
memoria sea ilegal en C, que sea ANSI C o algun otra variante.

int *p;
p = malloc(n*sizeof(int));
....bla bla
*(p+n) = 1234;

Es incorrecto obviamente. Pero no s� si es ilegal. Quiz� se describa
como ilegal en la especificaci�n, pero no me parece un argumento muy
potente en todo caso.

Incluso si es oficialmente ilegal, carece de significado. Si algo es
ilegal y no hay absolutamente ning�n mecanismo para "imponer la ley", su
ilegalidad es m�s bien te�rica. Por ejemplo, si hay un limite de
velocidad en una carretera de 100 km/h pero no hay ninguna vigilancia y
nunca te multan, ese l�mite no tiene importancia pr�ctica (por lo menos
en un pa�s latino -- un pa�s n�rdico es otra cosa ;-). (Por cierto, me
dijeron que todo espa�ol, seg�n la constituci�n, tiene derecho a empleo
y vivienda -- un derecho legal. No tiene mucho significado si no hay
nadie que proporcione empleo y vivienda a cada espa�ol.) El argumento
que haces sobre lo que es legal, a nivel pr�ctico, me temo, no tiene
mucha base real.

Pero todo eso nos lleva, como siempre, a la siguiente observaci�n.

La portabilidad en C es algo:

(1) definido de manera muy limitada

y 

(2) no tiene mucho significado pr�ctico.


El software (en mi opini�n ;-)) m�s interesante que est� escrito en ANSI
C es el JDK de Sun. Sin duda, escriben su c�digo de manera a que sea lo
m�s portable posible. No obstante, he observado que, cuando sacan un
nuevo JDK, la gente que tiene licencias Java -- IBM, Apple, y Netscape
entre otros -- tardan meses sino a�os en tener esa versi�n disponible
para su plataforma. (Es decir, en portar ese c�digo tan sumamente
portable...) El que se comporta mejor en este aspecto es IBM, sin duda,
pero es la empresa (aparte de Microsoft que no est� comprometido
realmente a la compatabilidad etc) que m�s recursos tiene. (Ya tienen la
1.2 beta para AIX disponible -- supongo que porque es otro UNIX y la
versi�n para Solaris se porta m�s o menos bien, pero no tienen a�n para
OS/2 y otras plataformas.)

Eso a nivel de empresas grandes que pueden dedicar muchos a�os-hombre al
tema de portar software. A nivel de gente como yo, un desarrollador
independiente, o incluso empresas peque�as, a nivel pr�ctico, esa
portabilidad casi no existe.

En el contexto de un foro sobre lenguaje Java, yo creo que es bastante
justo decir que "el C no es realmente portable". O bien, dicho de otro
modo, la portabilidad en el mundo C/C++ est� definida de forma tan
limitada, que no es lo que estamos llamando portabilidad en el mundo
Java en un principio.

> Por el contrario, un programa *ilegal* en C puede tener un
> comportamiento indefinido, o simplemente dependiente de la
> implementaci�n. <resto cortado>

Ese tipo de cosa me suena tecnicismo de abogado, no realmente un
argumento de ingeniero. La definici�n que propuse, que el mismo programa
produce el mismo comportamiento en distintas plataformas, de punto de
vista de ingenier�a, me parece ser m�s o menos la definici�n correcta.

> > Francamente, es tu definici�n de portabilidad
> >que es m�s bien dudosa, creo.
> 
> No es m�a, es de las organizaciones ANSI e ISO, que me da a m� en la
> nariz que de esto deben saber un poco.

Bueno, a m� lo que me da en la nariz es lo siguiente. En el comit�,
tienes representantes de los principales fabricantes de compiladores C,
que tienen muchas implementaciones incompatibles, y en vez de realmente
ponerse de acuerdo para hacerlos verdaderamente compatibles, redefinen
la palabra "compatible" o "portable" -- porque es m�s f�cil hacer eso
que hacer que las cosas sean compatibles o portables de verdad. 
Supongo que es una interpretaci�n c�nica de todo eso. Si eso
escandaliza, lo siento.

> >En la pr�ctica, tras una cierta escala, no hay sistemas sin ning�n bug
> >de ning�n tipo. Decir que no importa que el sistema falle en alg�n SO y
> >funciona en otro, porque el buen programa no tiene bugs en un principio
> >es pamplinas.
> 
> No es eso lo que he dicho. He dicho que no puedes basar tu c�digo en
> trabajar a base de excepciones. 

S�, bueno, pero la situaci�n de leer o escribir a un puntero inv�lido no
es precisamente muy excepcional en el mundo C. Es bastante cotidiano. No
obstante, el C no trata el problema. Decir "es ilegal" pero no hay
ning�n mecanismo que impone la m�s m�nima disciplina es realmente una
contradicci�n.

> >Si el C tuviese arrays, ser�an dos prototipos incompatibles.
> 
> No te confundas. El hecho de que punteros y arrays sean equivalentes
> en muchas ocasiones no quiere decir que sean totalmente
> intercambiables. De hecho, el est�ndar define cu�ndo son equivalentes
> y cuando no lo son; internamente cada compilador los puede implementar
> como le parezca, aunque lo l�gico es hacerlo mediante punteros.

Para m�, el C no tiene arrays. Para ser un array, debe tener un
principio y un fin. Dicho de otro modo, un array tiene una dimensi�n. En
ese sentido, el Java tiene arrays y el C no los tiene. Tiene sintaxis de
arrays implementada con punteros.

> 
> Por ejemplo, en C, esto es totalmente portable:
> 
> char cadena1[] = "cadena de texto";
> [...]
> cadena1[0] = "x";    /* cambia una letra */
> 
> Pero esto NO lo es:
> 
> char *cadena2 = "cadena de texto";
> [...]
> cadena2[0] = "x";    /* cambia una letra */
> 
> Igual que tampoco lo es, por ejemplo, (y muchos compiladores se
> negar�n a compilarlo) declarar una variable en un modulo como
> 
> char variable[] = "variable";
> 
> y referenciarla en otro como
> 
> extern char *variable;
> 
> Y much�simos otros ejemplos. La llamada "equivalencia" de punteros y
> arrays en C no significa que sean totalmente id�nticos. Son
> equivalentes, por ejemplo, como par�metros formales en una funci�n,
> pero en muchos otros contextos no lo son.

De hecho, ya era consciente de que hay diferencias sutiles en la
especificaci�n, pero a nivel pr�ctico, existe el mismo problema. El
puntero tiene un principio y ning�n fin definido. Pasar un array a una
funci�n es efectivamente lo mismo que pasar un puntero, y por lo tanto,
no es m�s o menos seguro que trabajar con un puntero crudo. Es realmente
una disposici�n muy primitiva. Es buscar problemas.

> 
> Para que te quede claro:
> 
> === Empieza ===
> 6.3:  So what is meant by the "equivalence of pointers and arrays"
>      in C?
> 
> A:  Much of the confusion surrounding arrays and pointers in C can
>     be traced to a misunderstanding of this statement.  Saying that
>     arrays and pointers are "equivalent" means neither that they are
>     identical nor even interchangeable.
> 
>     "Equivalence" refers to the following key definition:
> 
>         An lvalue of type array-of-T which appears in an
>         expression decays (with three exceptions) into a
>         pointer to its first element; the type of the
>         resultant pointer is pointer-to-T.
> 
>     (The exceptions are when the array is the operand of a sizeof or
>     & operator, or is a string literal initializer for a character
>     array.)
> === Acaba ===

Pero bueno, citas los escritos sagrados que casi nadie lee...  

"Hay te�logos jud�os y musulmanes que dicen que el catolicismo romano es
un tipo de paganismo porque tiene 3 dioses. Eso es falso. Creemos que
d�os tiene tres facetas, d�os el padre, d�os el hijo, y el esp�ritu
santo... pero, no obstante, bla bla bla... en catolicismo s�lo hay un
d�os."

(Espero que no he topado con algunos religiosos. Lo que quiero decir es
que todo eso es misticismo, que adem�s, prima facie, parece
contradecirse, o quiz� no se contradiga, yo que s�.. pero nadie lo
entiende realmente...)

En el fondo, que es la diferencia entre eso y:

"Hay fans de otros lenguajes que afirman que en C, los arrays, punteros,
y cadenas, es todo la misma cosa. Si es verdad que, bajo ciertas
condiciones, esas tres cosas son intercambiables, bla bla bla, las tres
cosas son elementos distintos...

�No es simplemente m�s misticismo, que s�lo los te�logos entienden?

(Bueno, y adem�s, si nadie lo entiende, �no quiere decir eso en el
fondo, que, a nivel pr�ctico, no hay una distinci�n muy clara
realmente...?)

> 
> >
> >>Pero eso
> >> es una facilidad que se da al programador, no una restricci�n. Otra
> >> cosa es que el programador no sepa usar esa facilidad y cometa
> >> errores. Pero esa es la discusi�n de siempre: mientras m�s libertad
> >> tienes, m�s cosas puedes hacer, y mientras m�s cosas puedes hacer m�s
> >> trabajo cuesta aprender cuando no sabes.
> >
> >Esto se dice mucho, pero... no tiene mucha base real. La libertad de
> >escribir a una direcci�n de memoria inv�lida no es realmente una
> >libertad. Realmente es como afirmar que el suelo est� lleno de porquer�a
> >y el hecho de limpiarlo me quita la libertad de tropezar y romperme el
> >culo. Bueno, es cierto quiz�s, pero no es libertad como la mayor�a de
> >gente entiende el concepto.
> 
> No hablo de la libertad de escribir a una direcci�n de memoria
> inv�lida, ni a la libertad de que tropieces en un suelo lleno de
> porquer�a. Hablo de la libertad de tratar los arrays y los punteros
> como tipos equivalentes, en las situaciones en la que est�
> perfectamente especificado que puedes hacerlo.

En el fondo, lo que est�s describiendo es la libertad de acceder a
memoria de forma inv�lida. Est�s hablando de la libertad de tratar
cualquier elemento -- un array, cadena, o en C++ un objeto -- como un
puntero crudo. Tengo serias dudas de que uno deber�a *querer* hacer eso.
Quiz�s si dieras un ejemplo... Yo sospecho que una dependencia de
punteros crudos en el c�digo que uno escribe suele sugerir un grave
problema de dise�o. Bjarne Stroustrup ciertamente cree que es algo que
evitar.
 
> La diferencia est� en que si no te interesa tratar punteros y arrays
> como tipos intercambiables en las situaciones en las que puedes
> hacerlo, pues simplemente NO lo haces. 

No siempre tienes esa libertad. Si utilizas el API de WIN32, o incluso,
las MFC, por ejemplo... 

> Mientras que en tu ilustrativo
> ejemplo, puedes perfectamente tropezar y romperte el culo aunque no
> quieras.

S�, pero en la pr�ctica, se puede decir que 100% de las veces que uno
tropieza y se rompe el culo, no era intencional. Pero es que ocurre... O
por ejemplo, puedes escoger conducir sin cintur�n sin *querer* sufrir un
accidente fatal por culpa de esa decisi�n. Creo que el ejemplo sigue en
pie.

En todo caso, la idea que esta libertad de romperse el culo produce
mucha eficacia en el c�digo resultante, la tratar� luego, ya que esto se
vuelve demasiado largo. Quer�a hablar de "la supuesta portabilidad de
C". La "supuesta eficacia de C" es algo que procurar� refutar luego,
cuando tenga un momento.

Saludos, 

Jonathan Revusky
-- 
Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions