Il n'y a pas d'erreur vis-à-vis de la norme POSIX d'utiliser un nombre sur 64 bits ou sur 32 bits on est d'accord. Tout ce que ton exemple montre, c'est que la norme POSIX est loin d'être une API d'interopérabilité parfaite, et que d'un système à l'autre il faut effectivement mieux avoir des bonnes pratiques de programmation si tu veux pas que ton programme face n'importe quoi.
En revanche je persiste : c'est une erreur s'il y a un changement dans la taille (passage de 32 à 64 bits) pour une implémentation/OS donné : même si tu codes à coup de time_t, cela peut casser la compatibilité de ton programme : tu peux te retrouver à bouffer plus de mémoire et atteindre une limite par exemple.
C'est d'autant plus dangereux que ton exemple pointe une incompatibilité API mais également ABI : imagine, un programme qui n'est même pas recompilé se retrouve à planter !
Clairement, dans ce genre de situation, il faut mieux créer une nouvelle méthode ou explicitement changer d'API.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à 0.
Il n'y a pas d'erreur vis-à-vis de la norme POSIX d'utiliser un nombre sur 64 bits ou sur 32 bits on est d'accord. Tout ce que ton exemple montre, c'est que la norme POSIX est loin d'être une API d'interopérabilité parfaite, et que d'un système à l'autre il faut effectivement mieux avoir des bonnes pratiques de programmation si tu veux pas que ton programme face n'importe quoi.
En revanche je persiste : c'est une erreur s'il y a un changement dans la taille (passage de 32 à 64 bits) pour une implémentation/OS donné : même si tu codes à coup de time_t, cela peut casser la compatibilité de ton programme : tu peux te retrouver à bouffer plus de mémoire et atteindre une limite par exemple.
C'est d'autant plus dangereux que ton exemple pointe une incompatibilité API mais également ABI : imagine, un programme qui n'est même pas recompilé se retrouve à planter !
Clairement, dans ce genre de situation, il faut mieux créer une nouvelle méthode ou explicitement changer d'API.