A ver, rir3760, explícame bien lo del problema con el avance de línea, porque según recuerdo una vez tuve problemas con eso. De ahí que siempre le pongo dicha prevención en el código. Tengo entendido además que por lo general los sistemas Windows codifican el fin de línea con dos caracteres (0x0D + 0x0A, o en decimal 13 + 10), mientras los UNIX usan simplemente el 0x0A.

Vamos por partes: Me tratas de decir que si por ejemplo fgetc() encuentra una sucesión CR + LF , entonces lee un sólo '\n' y avanza el indicador de posición de archivo en dos bytes, de modo que la próxima llamada a fgect() leerá el siguiente carácter después del LF. ¿¿Es eso así??

==============
Ah, y x64Core, no ingresé a este foro para pelear con nadie, sino para ayudar a los demás. Simplemente tengo una filosofía de que me gusta hacer las cosas a mano, en lugar de recurrir a recursos o softwares sofisticados.

Por ejemplo, uso la IDE más sencilla y sólo como editor, pues rara vez compilo usando los íconos de la barra de herramientas. Yo compilo desde la terminal y le meto yo mismo las directivas de "include" y de "lib" en la orden de compilación.

Hasta ahora me ha funcionado y he creado aplicaciones de cierta complejidad. Por supuesto me lleva más tiempo pero estoy seguro de que he construido y verificado POR MÍ MISMO cada línea de mi código, por eso confío en él.

De nuevo, no es por polemizar, simplemente es mi filosofía de trabajo. Cada quién tiene la suya y se le respeta  

Que bueno que puedas resolver con eso!!!

Por si acaso te sirve, el envío de un formulario a un servidor consiste simplemente de un mensaje HTTP de tipo GET o un POST, que en su cuerpo contiene parejas de nombre-valor. El atributo "name" de cada control del formulario seguido se su "value".

En el caso de imágenes es igual, pero el contenido del mensaje es simplemente el flujo de bits que forma la imagen. Es decir, el contenido bruto del fichero de imagen. Pero en la cabecera del mensaje debes especificar el tipo MIME del documento, que por ejemplo para una imagen GIF debe ser  "image/gif"

Hola ...... Mira mi consejo es "matar la serpiente por la cabeza". Busca siempre la solución MAS SIMPLE, y evita cualquier posibilidad de error. Y no te compliques buscando códigos por toda la web, y repito, medita hasta encontrar la solución más lógica y simple.

Si quieres convertir el arreglo:

unsigned char buffer[2] = {0x00, 0x02};
 

en 0x0200, de una manera independiente de la arquitectura, pues simplemente has la aritmética:

unsigned short int word1;
 
word1 = 0x0100 * buffer[1] + buffer[0];
 

así que te dará: 0x0100 * 0x02 + 0x00 , o en decimal 256 * 2 + 0 = 512

Listo  

¿La lógica de esto? Veamos, pensando en decimal .... ¿cómo conviertes el arreglo {2, 3} en el número decimal 23? Pues, multiplicas la parte más significativa (el orden de la parte más y la menos significativa la defines tú en el software) por la base numérica, y le sumas la menos significativa. En tu caso, la "base" resultante de agrupar en lotes de 8 bits (o sea, bytes) será 256, o 0x0100.

En caso que quieras llevar un arreglo de cuatro bytes a un entero de 32 bits (para lo que requieres declarar long int) debes usar la fórmula:

unsigned ong int dword1;
char buffer[4];
 
/* aquí llenas el buffer */
 
/* luego convertimos */
dword1 = 0x01000000 * buffer[3] + 0x010000 * buffer[2] + 0x0100 * buffer[1] + buffer[0];
 

que es algo así como hacer:

dword1 = 256^3 * buffer[3]  + 256^2 * buffer[2] + 256 * buffer[1] + buffer[0];
 

=====================
Nota (sobre los tipos int): El estándar ANSI C especifica que el tipo "short int" lleva como mínimo 16 bits, por que lo que alcanza para almacenar un doble byte. Especifica también que el tipo "long int" lleva como mínimo 32 bits, y que "int" mayor a "short int" y menor o igual a "long int". Así que "long int" alcanza con seguridad para el tipo cuádruple byte.

Esta solución es independiente de hardware, y no fallará siempre y cuando el compilador respete los tipos enteros definidos por el estándar ANSI C, que es algo que seguro se cumple!!

... Espero te sirva ....

Pues la razón es más que clara, te equivocaste con las mayúsculas/minúsculas al escribir la función en uno y en otro sitio. Recuerda que C es sensible a mayúsculas y minúsculas.

La función que declaraste es [/tt]modificarClientes()[/tt], pero luego mencionas una ModificarClientes() (con 'M' en lugar de 'm') que no ha sido definida. De ahí el error.

¿Te has preguntado por qué no falla al compilar pero sí al enlazar? Te explico un poco como funciona C. El proceso de generar un ejecutable se divide en compilado y enlazado (linkado). Cuando encuentra una llamada a una función que no está definida es ese mismo archivo fuente, pero supone que está en otro, simplemente queda indicada una "referencia por resolver", y no pasa nada. Es decir, deja como "huecos" en el programa. Por eso el compilador no genera error.

Luego, el enlazador debe encontrar todas las referencias sin resolver y resolverlas; es decir, hallar los códigos fuente de las funciones pendientes por definir en el programa principal. Si no los consigue, entoces se produce un error de linkado y no se genera un ejecutable. Fue lo que ocurrió al buscar la definición de la función ModificarClientes() y no encontrarla ...

Sí, efectivamente la función system() está incluida en la biblioteca <stdlib.h>, que es la biblioteca de utilerías generales de C.

Con el tiempo terminarás memorizando cuáles funciones van con cuáles bibliotecas. En general se requieren mínimo dos: <stdlib.h> y <stdio.h>. La primera contiene a system(), además de otras importantes como malloc(), calloc(), realloc(), y free(). La segunda es para "input-output", es decir maneja las funciones de entrada/salida. Contiene printf(), scanf(), read(), write(), etc.
Otras bibliotecas importantes son <string.h> para cadenas, <time.h> para manejar fecha y hora y <math.h> para funciones matemáticas. Esto por mencionar algunas.

Ahora, en cuanto a system() considera que esta función lo que hace es pasar su cadena argumento al procesador de comandos del Sistema Operativo, como lo es cmd en caso de Windows, o bash en caso de Linux. Es como si escribieras ese comando en la consola, pues. Esto significa que el comportamiento de la función será absolutamente dependiente del sistema operativo, y por supuesto las sentencias de uno pueden no funcionar en el otro. Por ejemplo, si quieres listas los ficheros dentro del directorio actual debes escribir


en Windows, mientras:


en Linux y sistemas UNIX. Por eso no se recomienda system, ya que hará el programa no portable.

Si lo que quieres es una simple pausa usa, como te han recomendado, la función estándar getchar() de <stdio.h>.

Ojo, que no es getch(), ni tampoco getche(), !!!!!!

La razón por la que se haya tan difundido el bendito system("pause") es que muchos profesores y academias no enseñan el "verdadero" C, normado por los comités ANSI e ISO/IEC, sino la versión de C de Borland, o la de Microsoft Visual C++ que no son estándares oficiales sino versiones COMERCIALES de ciertas compañías.

Pero se tú un buen estudiante, y aprende el C "académico", o sea el verdadero y hazlo así desde el principio  

..... Yoel ......

Bueno, .... no entendí exactamente lo que quieres indicar con el mensaje, pero me imagino (porque también he trabajado con eso y me ha dado dolores de cabeza) que el problema puede estar efectivamente en la asignación de memoria para probes.

No se cómo lo estás haciendo pero si por ejemplo el probes debe ser un array de digamos 10 cadenas, cada una con capacidad para 50 caracteres (más el nulo de terminación), hay que hacer:

probes = (char **) malloc( 10 * sizeof (char *) );
if ( probes == NULL ) return;      /* comprueba integridad */
for ( i = 0; i < 10; i++ ) {
    probes[i] = (char *) malloc( 51 * sizeof(char) );
    if ( probes[i] == NULL ) return;
}
 

Es decir, reservas espacio en probes para 10 strings, o sea, 10 punteros a char. Es bueno siempre verificar si malloc pudo asignar efectivamente memoria, probando si el puntero devuelto es distinto a NULL. De lo contrario, la asignación fue fallida y debes salir o reiniciar el programa. [de otro modo se puede producir una "fuga de memoria" y ya empezarás a parecerte a los programadores de Microsoft, jeje  ]

Luego, en cada elemento del array probes debes colocar un puntero (devuelto por malloc) a una zona de memoria con espacio para 51 elementos de tipo char, es decir, una cadena con espacio para 50 caracteres más el nulo de terminación (no se te olvide el espacio para el nulo). De nuevo, verifica el retorno de malloc después de cada llamada a la misma.

Ahora sí puedes empezar a llenar el array probes con cadenas con (en este caso) 10 cadenas de longitud 50 cada una. En tu caso, si por casualidad los elementos de probes no estaban correctamente inicializados, y eran simplemente punteros NULL, esa es la razón por la que sprintf no escribió nada en request !!

Hola ThronerAXE, en cuánto al código me parece bien salvo por un pequeño detalle. Al menos en mi compilador de C++ (uso g++ de GNU para Linux) la biblioteca iostream debe ser cargada con la sentencia:

#include "iostream"
 

en lugar de <iostream.h>. La explicación exacta del por qué no la tengo, pero parece que iostream es más que un simple archivo de cabecera, es como varias cosas que se cargan juntas (o algo así, no se). En fin, el asunto es que en los compiladores más recientes (no así en los antiguos) hay que escribir "iostream" (sin .h)

Lo demás está bien. Ahora, en cuanto al orden de los argumentos en strcpy te explico. El prototipo de esta función es:

char * strcpy( char * destino, const char origen )
 

o sea, que PRIMERO va el destino, y de SEGUNDO el origen. Debe ser así, y no al revés. Entiendo que en el constructor de la clase tú desea copiar la cadena nombre a la cadena nom, por tanto debe ser, obligatoriamente:


Por razones similares debe escribirse num = numero y no al revés. Pues, el operando a la izquierda del operador "=" es quién recibe el valor.

Ante cualquier duda sobre el orden y significado de los argumentos en una función estándar de C debes remitirte a la documentación (help) de tu compilador, a un buen libro/manual de C, o ayuda en línea por ejemplo en la excelente página c.conclase.net, y por sobre todo atender a la descripción indicada por el prototipo de la función.

Espero haberte ayudado, y cualquier cosa vuelve a preguntar ....

Eso se llama poner el teclado en "modo POSIX no estándar", o modo RAW. Yo lo se hacer en C, pero no lo he intentado en BASH (aunque no debe ser difícil). Lo que pasa es que el estándar POSIX establece que la entrada de teclado se realiza presionando ENTER al final, pero LINUX tiene la opción de pasar a modo no-estándar o modo RAW (crudo).

Usando algo que se llama ioctl's se puede hacer, hay un servicio que te permite establecer el modo del teclado. Ahora si quieres un código en C que lea directamente la tecla pulsada, o más precisamente una versión para LINUX de la función getch() de Borland, aquí tienes este:


Este código funciona y te devuelve el código ASCII de la tecla pulsada. Así puedes construir algo como:


Esto no es para BASH sino para C, entonces si lo quieres invocar desde BASH haz un ejecutable y lo invocas desde BASH.

P.D. 1) Hay soluciones directamente para BASH, creo que con el comando "stty", pero no lo conozco bien (aún).
2) Estoy casi seguro que el código de getch() que suministré aquí es redundante y se puede optimizar. No lo he hecho, sin embargo en esta forma tosca se que funciona así que lo puedes usar.
3) Debes ser propietario de la consola, o sea, del fichero especial /dev/console para poder usar este programa. En LINUX eso significa que, o ejecutas como root, o "setuidas" el programa, porque /dev/console tiene a root como propietario.

Pero cuidado, el hecho de que no sea tipo f, no significa que sea un directorio. En UNIX existen tipos de fichero que no son ni directorio ni archivo normal, como links simbólicos, o dispositivos especiales de bloque.

Sí se puede, aunque yo personalmente no lo he intendao (quiero hacerlo en un futuro). Hay una biblioteca de socktes, no se dónde se ubique en sistemas Windows pero en GNU/Linux es <sys/socket.h> y posiblemente haya que añadir <sys/wait.h> y <netinet/in.h>

Luego debes usar algunas funciones como socket, bin, listen (esto en LINUX pero creo que es igual para Windows). En la página http://www.chuidiang.com/clinux/ busca el apartado de sockets y te explican paso a paso cómo debes hacerlo y qué funciones debes usar. Incluso incluyen un ejemplo resuelto, con el código fuente y todo (en Español).

Espero te sirva y ayude ...

====================
Por cierto, como todo esto es para Linux, si quieres que sea compatible con Windows (si es tu caso) usa un compilador de C de GNU para Windows, así muchas de las funciones de GNU funcionarán correctamente en Windows. Descárgate MinGW de la página http://www.mingw.org/ y busca la ruta del ejecutable gcc.exe, luego la añades a la variable de entorno PATH y ya puedes compilar con este compilador de GNU. Si quieres más detalles de cómo hacerlo dime y te indico.

Es posible que si usas otro compilador como el de BorlandC (estoy especulando, la verdad no se a ciencia cierta) no te funcionen los ejemplos para Linux dados en chuidiang.com