randy@halcdc.UUCP (randy orrison) (11/17/88)
In article <674@quintus.UUCP> Brandon Allbury writes: |[Aaaaagh. I always suspected gets() was a potential bomb. How about | |#define gets(s) fgets(s, sizeof s, stdin) | |as a quick fix? ++bsa] { char *s; s = malloc (80); gets (s); } Two problems: the space after gets would kill it if it's a macro, and sizeof (s) != 80 (on most machines). Which means that you'd have to examine your code to make sure the macro would work, and fix it if not, so why not just fix it to use fgets? -randy -- Randy Orrison - Control Data in the Hills of Arden randy@halcdc.uucp aka randy@{ux.acss.umn.edu, umnacvx.bitnet, cctb.mn.org, umn-cs.uucp} ZQOTD: "Make me look like LINDA RONSTADT again!!"
guy@auspex.UUCP (Guy Harris) (11/18/88)
>|#define gets(s) fgets(s, sizeof s, stdin) ... > gets (s); >Two problems: the space after gets would kill it if it's a macro, Say WHAT? Works fine on all the compilers I know of. "Preprocessor" macros don't require that you give the exact same amount of white space in the invocation as you gave in the definition; if your compiler requires this, get it fixed!
randy@halcdc.UUCP (randy orrison) (11/19/88)
In article <468@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: |>|#define gets(s) fgets(s, sizeof s, stdin) |... |> gets (s); | |>Two problems: the space after gets would kill it if it's a macro, | |Say WHAT? Works fine on all the compilers I know of. "Preprocessor" |macros don't require that you give the exact same amount of white space |in the invocation as you gave in the definition; if your compiler |requires this, get it fixed! Obviously correct. (Sorry Brandon!) What I was thinking of was the time i tried something along the lines of: #define gets (s) fgets(s, sizeof s, stdin) ^ which fails for obvious reasons. However, it still doesn't work for cases where s is a pointer instead of an array - say, if it's a parameter in a function, or declared as a char * with memory allocated for it. It's not something you could stick in at the top of someone else's code to make it secure, and it's not something you'd want to use in original code (which you could do right). -randy -- Randy Orrison - Control Data in the Hills of Arden randy@halcdc.uucp aka randy@{ux.acss.umn.edu, umnacvx.bitnet, cctb.mn.org, umn-cs.uucp} ZQOTD: "Yow! It's a hole all the way to downtown Burbank!"
henry@utzoo.uucp (Henry Spencer) (11/23/88)
In article <122@halcdc.UUCP> randy@halcdc.UUCP (randy orrison) writes: >|>Two problems: the space after gets would kill it if it's a macro, >| >|Say WHAT? Works fine on all the compilers I know of. "Preprocessor" >|macros don't require that you give the exact same amount of white space >|in the invocation as you gave in the definition... Definitions of parameterized macros ("function-like" macros in X3J11speak) have always been required to have the "(" immediately following the identifier. The May draft standard requires that in the invocation, the "(" must be "the next preprocessor token", which basically means that white space there is okay. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
guy@auspex.UUCP (Guy Harris) (11/24/88)
>>|Say WHAT? Works fine on all the compilers I know of. "Preprocessor" >>|macros don't require that you give the exact same amount of white space >>|in the invocation as you gave in the definition... > >Definitions of parameterized macros ("function-like" macros in X3J11speak) >have always been required to have the "(" immediately following the >identifier. And therefore, since uses of parameterized macros don't require that, preprocessor macros don't require that you give the same amount of white space in the invocation as you gave in the definition....