Independientemente de que el estándar contemple o no contemple estas situaciones lo cierto es que un algoritmo así jamás debería llegar a producción. Cualquiera de estas situaciones genera un warning (este aspecto me sigue pareciendo bastante serio ya que deberían ser errores) que debería ser correctamente atendido. Yo además soy partidario de tratar los warning como errores, por lo que el programa directamente no compilaría.

@eferion si, también soy amigo de -werror, pero el tratamiento que le demos a las alarmas no es el tema de la pregunta. Me gustaría saber qué debo interpretar, estándar en mano, en esa situación.

Hace no muchó leí en un blog que estadísticamente la gente nueva cometía menos errores a la hora de resolver códigos (en competición) y el motivo principal es la tendencia a regirnos por reglas más estrictas cuando tenemos una base de conocimiento suficiente. No hace falta revisar ningún estándar para saber que eso no se ha de hacer. Una función SIEMPRE ha de devolver algo porque es lo que aquel que la consuma va a esperar y un método NUNCA ha de devolver nada porque nadie va a hacerle caso.

@eferion es un debate interesante, tal vez da para chat, pero sigue sin ser respuesta a lo que ha motivado mi pregunta. Si bien es cierto que esto no debería suceder quiero saber lo que el estándar define que puede pasar en caso de que suceda (que si puede suceder: sucederá).

Además C tiene el añadido de que es un lenguaje que casi roza el ensamblador y con muchos años a sus espaldas que es utilizado en infinidad de sistemas. Esto hace que corregir defectos del lenguaje sea complicado porque es complejo evaluar todas las posibilidades. Lo mejor es evitar las malas prácticas ya que raramente son necesarias. Y en serio entiendo que quieras conocer cual es el comportamiento que dicta el estándar... pero creo que es una de esas situaciones en las que no es necesario ser tan estricto y simplemente basta con saber que ese código no es correcto.

@eferion mira este ejemplo, conceptualmente es válido ¿qué debo esperar de ello? double my_sqrt(double d) { if (d<.0) return; /*salimos si d es inoperable*/ return sqrt(d); } es evidente que no es la manera de solucionar el problema de raíz cuadrada pero conceptualmente es algo válido y es código que he visto aceptado en producción.

Si compila, que siendo C compilará, yo ni me molestaría en mirar el estándar porque lo primero que me queda claro es que ese código es incorrecto. C deja hacer muchas cosas y no por ello han de ser válidas (como castear un puntero a un char, por ejemplo). Yo he visto código similar y sí, vale, compila y aparentemente funciona... pero luego he visto dolores de cabeza porque al cambiar de compilador el programa ni tan siquiera arrancaba.

@eferion luego he visto dolores de cabeza porque al cambiar de compilador el programa ni tan siquiera arrancaba y ahí la importancia de saber qué comportamiento define el estándar en ciertas situaciones. Si el compilador no sigue el estándar entonces el problema es otro :)

Viendo la gente que habitualmente responde a problemas de C yo te diría que la mejor opción es plantearlo en la versión inglesa. La cantidad de gente que te puede responder es sustancialmente mayor y ahí hay gente cuyo corazón late gracias a un bucle hecho en C.

De hecho ya lo hice :) si te fijas en la fecha/hora de las publicaciones: son simultáneas.

Esto me recuerda a hace un tiempo, que vi un proyecto que compilaba con errores... pero como la ejecución nunca pasaba por dichos errores el programa corría correctamente.

Por cierto, hacía mucho tiempo que quería charlar contigo; me encantan tus respuestas y te odio un poco porque te me adelantas respondiendo ¿de qué franja horaria eres?

jajajajjaa

a mi eso me ha pasado también a veces

y gracias por el halago

Soy de madrid

Ya decía yo que debías ser de España, pues solemos tener actividad en el mismo horario. Yo soy de Barcelona.

tus respuestas tambien son bastante buenas. Si no respondo en hilos por donde has pasado tu es porque tu respuesta sola se bastaba

Nunca he oído de un programa que compilara con errores, lo máximo alarmas.

era un compilador antiguo y las librerías las generaba aunque diesen errores... no me preguntés ni cómo ni por qué

luego con la librería montada podías generar el programa

Muchas veces he estado tentado en responder en preguntas que ya respondiste, pero suele ser futil, tus respuestas son muy buenas :)

Llevo 5 años usando C++ a diario... de algo tenía que servir

Eso sí, es en ese momento cuando te das cuenta de lo mala que es la enseñanza en este campo al menos en españa

Ufff... me apena no saber qué compilador era, quería hacer pruebas.

Y comprobar su adhesión al estándar.

Yo llevo con C++ más de 10 años :)

Btw: ¿Conoces las charlas using std::cpp en la Carlos III de Madrid?

He oído hablar de ellas pero nunca he estado... falta de tiempo

Y cuando tenía tiempo, que es cuando estudiaba, mi prioridad no era C++

Si no me equivoco 2016 será su 4º año; tengo previsto ir (aún no me he perdido ninguna edición). No deberían tardar en anunciarlas (me extraña que no lo hayan hecho aún).

Por cierto, quise etiquetar esta pregunta con language-lawyer cuya etiqueta no está en SOes, pero no sabía que traducción asignarle. ¿Qué opinas?

Yo creo que con la etiqueta de C es suficiente

De aucerdo, así se queda pues. :)

C++ también come burradas guapas, no se libra del pecado.

El problema es que esas cosas son alarmas y deberían ser errores, no entiendo ni por qué está definido en el estándar como UB.

Seguramente, de fondo, debe haber algún motivo técnico muy específico que dejándolo como UB permita a los compiladores hacer alguna brujería para sacar mejor código, pero debería investigar más para estar seguro.

Con cualquier lenguaje se pueden hacer burradas. La responsabilidad final ha de ser del programador, pero en el caso de C es que nunca comprueba nada.

C++ también pasa muchas cosas por alto, sobre todo hasta la llegada de C++11; a partir de 11 se pudieron controlar mejor las cosas pero se sigue pudiendo hacer código peligroso :O

En fin, me ha encantado chatear contigo. El chat era una mera excusa para felicitarte por tu trabajo en la comunidad y establecer mi sana rivalidad contigo :) me retiro por hoy.

perdón, me llamaron por teléfono.

Me alegra saber que el sentimiento es mutuo.

Hasta la próxima