Mensajes

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364428(v=vs.85).aspx

Con esas 2 funciones tienes para empezar

http://pubs.opengroup.org/onlinepubs/007904975/functions/setenv.html

No obstante, resulta extraño que, siendo valores aleatorios, en otro ordenador, ejecutando el programa, el valor de n siga valiendo 1 si no la inicializas. Es como si el propio compilador la inicializara a 1 por algún motivo...
Lo que me demuestra que debe ser el compilador es que si ahora declaro 2 variables tipo int; por ejemplo "p" y "n", sin inicializar, me dan dos valores "aleatorios"
n=4294156 y p=4248043. Resulta que si ejecuto el mismo programa en otro PC, ¡me dan los mismos valores!
Da igual cómo llame a las variables. Esto quiere decir que el compilador "da" unos valores a las variables; o algo así... En fin, no sé si darle más vueltas a estas chorradillas.

Saludos...no perdáis el tiempo por mi.

En este caso la palabra aleatorio deberia de ser reemplazada por "valor no garantizado" puede ser 1, 129308129038 o cualquier otro numero, puede ser el mismo en varios PC (por la manera que el windows inicializa el stack) pero el tema es que nada te garantiza el valor inicial.

Tendras que mirar por que te da error en la linea, fijate que es lo que hace la linea y las posibles razones por la que puede petar

Tienes que cambiar send por sendto

http://msdn.microsoft.com/en-us/library/windows/desktop/ms740148(v=vs.85).aspx

Y no te preocupes por los errores, todos comenzamos de la misma manera

Algunas cosillas que he visto

Estas haciendo que bind "falle" al compararlo usando not (!), bind devuelve 0 cuando se completa correctamente, basicamente el programa te esta diciendo que ha fallado cuando en realidad no ha fallado, cambialo por if (bind(...) == -1) { error }

Usas connect en un socket udp (los sockets udp son connectionless), el efecto de connect en UDP es simplemente poner un destinatario por defecto para las llamadas de send, yo evitaria usar connect y usaria directamente sendto

Prueba usar bind en el socket con la ip como INADDR_ANY y el puerto de origen que tu quieras

[naderST]

Por lo visto tenemos una confusión, a ver si ahora me explico mejor.

Cuando indique que el proceso no es acumulativo me refería a la llamada a "malloc", no al incremento del contador "i".

Cuando se reserva memoria la variable "arreglo" sirve como bandera para saber si la reserva fue exitosa o no. Después de ello se libera pero eso no importa porque basta con revisar el valor de esa variable para conocer si funciono (diferente de NULL) o no (NULL).

Si por curiosidad se desea conocer si es posible realizar la máxima (en teoría) reserva de memoria basta con:

Código (c) [Seleccionar] Expandir

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
   size_t max = -1;
   char *p;
   
   p = malloc(max);
   free(p);
   
   if (p)
      puts("OK");
   else
      puts("Error");
   
   return EXIT_SUCCESS;
}
El programa anterior de naderST realiza (poco mas o poco menos) lo mismo: acercarse al punto donde la reserva de memoria falle.

Un saludo

Cierto, my bad, no se por que veia un 1 en donde es una i (malloc), no dormir hace estragos XD

No. Las llamadas anteriores no importan porque la intención no es realizar un proceso acumulativo.

Si se llama a "malloc" y esta falla su valor (NULL) se almacenara en la variable "arreglo" y eso causara la salida del bucle.

Un saludo

La intencion ES hacer un proceso acumulativo, ese es el objetivo del programa, calcular cual es el tamaño maximo de un array antes de que el sistema se quede sin memoria, el tema es que la intencion se ve inutilizada por el hecho de que desues del malloc hace un free, lo cual hace que nunca salga del bucle, descomenta el free y veras como esa accion si afecta al bucle, no instantaneamente, pero si cuando el sistema se quede sin memoria y en la siguiente iteracion malloc retorne NULL

No. La variable "arreglo" contiene la ultima direccion retornada por malloc, la liberacion de memoria en la siguiente sentencia no afecta la condicion del bucle.

Si piensan ejecutar un bucle asi seria mejor cambiar el incremento a 1 KB o 1 MB.

Un saludo

Si que afecta, fijate mejor xD

El bucle acabara cuando el sistema se quede sin memoria y retorne NULL, eso nunca pasara por que hace free a la memoria que reserva.