Mensajes

Así es.

Pues buscas el nodo que el siguiente sea el dato buscado.
Haces que el inició de la lista apunte al siguiente dato.
Haces que el el final de la lista apunte a lo que era originalmente el inicio de la lista.
Haces que el nodo en el que estás apunte su siguiente a NULL.
Necesitarás alguna variable pnodo auxiliar.

¿Qué tal si modificas tu primer post y pones el código entre etiquetas geshi o code? Gracias.

Y si el ejercicio se hace con una pila en vez de una lista se hace casi todo de forma automática.

Directamente no se puede hacer: tlista solo tiene un miembro que apunta a un pnodo, por tanto desde un tlista pasado como argumento no se puede ir al siguiente. Se me ocurre que con algo de trabajo y variables static podría ser, pero es hacer un código muy feo.

Lo mejor sería hacer algo así:

Código (c) [Seleccionar] Expandir

static int sumar_interno(pnodo nodo) {
    if(!nodo)
        return 0;
    else
        return nodo->dato + sumar_interno(nodo->sig);
}

int sumar(tlista *lista) {
    if(!lista)
        return 0;
    else
        return sumar_interno(lista->inicio);
}

Esto haría que la interfaz fuera sumar, pero ésta llamaría a sumar_interno quien haría realmente todo el trabajo; y esta sí puede iterar sobre sí misma pues un pnodo sí forma realmente la lista.

Eso era en tu primer código. Líneas 43 y 44:

Código [Seleccionar] Expandir

case 2: crear(nuevonodo); if(nuevonodo!=NULL){agregar_inicio(milista,nuevonodo);}; break;
case 3: crear(nuevonodo); if(nuevonodo!=NULL){agregar_inicio(milista,nuevonodo);}; break;
En los dos cases añadías al inicio.

¿Por qué buscar_nodo solo devuelve si lo ha encontrado o no? Mejor si devolviera el puntero al nodo, en caso de existir, o NULL (nullptr) en caso de no encontrarlo. Saber si existe o no no tiene utilidad. Sí tiene utilidad el devolver el dato pues, normalmente, suele llevar más datos que el que ha sido objeto de búsqueda.

Por otra parte ¿qué no entiendes? Explicar todo el código cómo que es un poco largo.

Eso se llama guarda.
En ese momento aún no ha entrado en marcha el compilador, es el preprocesador quién está haciendo su trabajo para darle el código al compilador en la siguiente fase.

Para entender qué ocurre deben saberse unas cuantas cosas antes:
Un símbolo sólo se puede declarar una única vez.
Para poder usar objetos y funciones el compilador debe conocer su tamaño con anterioridad. Las librerías son objetos y funciones genéricos que se pueden usar en multitud de programas diferentes.
Para eso existen los archivos de cabecera: declaran esos símbolos para que el compilador sepa usarlos.
Una librería puede depender de otra, por lo tanto incluirá esa cabezera y si incluyeras las dos librerías en tu código tendrías el error de haber declarado dos veces el mismo símbolo.

Bien para solucionar eso están las guardas del preprocesador, que simplemente es mirar si existe un símbolo. Sí éste existe no hacer nada, pero si no existe se hace todo el trabajo necesario.
Con el

Código [Seleccionar] Expandir

#ifndef LIBUSBI_H
El preprocesado mira si el símbolo LIBUSBI_H ha sido definido con anterioridad.
Si está definido el preprocesador saltará hasta #endif.
Si no está definido lo primero que se hace es definirlo (poner la guarda para evitar que se repita la definición)

Código [Seleccionar] Expandir

#define LIBUSBI_H
Y a partir de aquí todo el código para declarar objetos y funciones.

En API Windows ni idea.
Pero la idea sería que volvieras atrás el puntero del archivo tantos bytes como leíste, grabas  tantos bytes como leíste y continuas con la siguiente escritura.

Un fseek si se usara la biblioteca estándar.

Te está preguntando por main.