tag 451886 + wontfix thanks On Mon, Nov 19, 2007 at 05:16:29AM +0000, Andrew Buckeridge wrote: > package: libc6 > version: 2.3.6.ds1-13etch2 > severity: wishlist > > Possible partial fix for fgets and alternatives. > > Bug #57729 is marked as done. It could be fixed for real. > I have found null escapes a pretty reliable way of breaking many C > programs including various editors. > > The standard C <stdio.h> fgets function is just plain wrong. > > fputs stops at a '\0', but fgets may only stop at '\n' even if a '\0' > is encountered. There is no way of knowing how much is read by fgets. > These functions are inconsistent and are not binary safe. > > The standard should be fixed. The libc will follow the standard, and the standard will never ever "fix" things like that. If you're going to read binary data, indeed, you should not use FILE* or fgets, but plain read(1) calls with non blocking sockets in a select loop. Anyway, the glibc _packaging_ team will never ever take the liberty to introduce new symbols that arent in the upstream glibc, it would be way too disruptive, so please bring this upstream, we don't have the resources to do that for you. and yes btw fputs stops at the first \0 because it puts a string, and strings in C are NUL terminated. fgets has a disruptive API, and _yes_ I would very much prefer that fgets had this API intead of the current: ssize_t fgets(char *buf, size_t len); with the usual semantics that -1 means error (with errno set properly), and else the return value would be the amount of bytes written in the buffer buf, not counting the last '\0', meaning that the return value would be at most equal to len - 1. Or even name this fgetline as it's what it does for real. Sadly it's not the case, blame the C committee. Meanwhile I'm leaving that bug as wontfix. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpJxz83neWRC.pgp
Description: PGP signature