Re: worst.c - foolishness

From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 01/13/04


Date: Tue, 13 Jan 2004 14:55:09 -0500 (EST)


On Tue, 13 Jan 2004, Jarno A Wuolijoki wrote:
>
> On Mon, 12 Jan 2004, Arthur J. O'Dwyer wrote:
>
> > > char *fmt = "%d, %l";
> >
> > These two lines should probably be combined. Note the subtle change
> > in the indentation, also.
> > char *fmt = "%d, %l", c;
>
> ITYM
> char* fmt = "%d, %l", c;

  My mistake. ;-)

> It would be better though if c was somehow used as if it were a
> char* instead. Otherwise it just adds up to obfuscation.

  I think you'd have trouble avoiding a compiler warning in that case.

> > > unsigned int z;
> > > while (!feof()) {
> > Surely you meant
> > while (!feof(stdin)) {
> > This will avoid the warnings from those so-called "smarter" compilers. :)
>
> Dunno, it's one bug less if you ignore the misdefinition..

  How so? My change merely replaces "undefined behavior upon calling
unprototyped function with wrong arguments" (which Chuck already had
elsewhere) with "undefined behavior upon passing NULL to feof()". Plus,
my bug is much subtler.

> > > if (EOF == c) continue;
> > > }
> >
> > You're missing a
> > scanf("%d", z);
> > here.
> >
> > > gets(&c);
>
> My linker warns about gets so I'd fuse these two into one scanf. You
> can use c as if it was a pointer there too.

  Doesn't that remove the bug, though? scanf("%d%s", z, &c) will
most likely try to store a string in the memory pointed to by &c
(invoking undefined behavior on buffer overrun); but the bug I was
trying to introduce there was that

  scanf("%d", &foo);
  gets(bar);

will store a number in 'foo', and then, assuming the user has pressed
'Return' to end that line of input, will proceed to read and discard
a single newline. OTOH, the gets() doesn't actually have a bug then;
it will store only a single '\0', won't it? So maybe keep that gets(),
but introduce the

  scanf("%d", &foo);
  fgets(&c, sizeof &c, stdin);

bug(s) elsewhere in the code. [Bugs include lack of prototype for
fgets, causing undefined behavior when passing literal 0 as third
argument; mis#defined 'stdin' that causes the literal 0 in the first
place; passing NULL to fgets in the first place; buffer overflow;
abuse of the 'sizeof' operator; lack of error-checking on scanf;
and the above-mentioned mishandling of possible newline characters
in the input.]

> #define EOF -1
> #define stdin 0
> #define swap(__a, __b) (__a ^= __b ^= __a ^= __b)
>
> char* strfmt = "%d, %l", strtmp;
>
> main()
> {
> int x, y;
> char c;
> unsigned z, zz;
>
> while (feof()==EOF) {

  I think the use of == for != is too blatant a mistake. But it
occurs to me that we haven't misused De Morgan's Rule yet; we need
something along the lines of

     while (feof()!=EOF || c=(int)getchar() != EOF) {

[I like my cast better than yours. Yours is only designed to
placate the compiler, AFAICT; mine has the "good" intention of
making sure the result of getchar() is wide enough to hold 'EOF'
before assignment to c. ;-) ]

> c = (char) getchar();
> if (c<0) continue;
> }
> scanf("%d%s", z, strtmp);
> printf(strfmt, strtmp, x);
> fflush(stdin);
> for (z = sizeof strfmt; z>=0; z--) for (zz = z; z>=0; zz--);
> if (strfmt[z]-strfmt[zz] <= 0) swap(strfmt[z], strfmt[zz]);
> strfmt = (char*) malloc(123);
> (void) realloc(&strfmt, 245);
> y = strfmt[1000];
> if (z>0) return -1;
> else return main(42.7f);
> }

  Finally, it occurs to me that we haven't abused 'goto' yet, nor
attempted to 'switch' on some inappropriate type. Nor even inserted
anywhere an

     if (strfmt == "foo")

;-)
-Arthur
[Disclaimer: THIS WHOLE THREAD IS A JOKE. THIS IS INTENTIONALLY
BAD CODE. WE KNOW IT DOES NOT WORK. :) ]



Relevant Pages

  • Re: worst.c - foolishness
    ... My change merely replaces "undefined behavior upon calling ... > my bug is much subtler. ... > will store a number in 'foo', and then, assuming the user has pressed ... I don't like the doublecheck for eof though. ...
    (comp.lang.c)
  • Re: Buffer overflows and asctime()
    ... legalese tend to get lost in their word mazes and loose ... the technical knowledge that should be the basis of ... what is a BUG and how to fix it. ... This call to strcpyinvokes undefined behavior. ...
    (comp.std.c)
  • Re: lcc-win32
    ... > timeptr produce undefined behavior in the sample algorithm (for ... > I think that this was the wrong answer to give to a bug report. ... If you wish you can write a supervisory function to do the error ...
    (comp.lang.c)
  • Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current)
    ... Previously, we implemented that undefined behavior by accident: we appear to be improperly checking for access, but due to the flexibility of the checks, we grant them. ... We need to now implement the undefined behavior on purpose, since the new access control implementation is structured. ... A bug in the new ipcpermmay well be triggering the appearance of the error, but it appears also to be a product of incorrectly structured code in the existing shared memory implementation. ... We grant only valid rights, ...
    (freebsd-current)
  • Re: stores in [O] [comp]
    ... I looked at the code, and found a possible bug, but I don't think it ... overwrote the store counters with random numbers. ... it seems that there is a problem with wand stacking. ... different numbers of charges. ...
    (rec.games.roguelike.angband)

Loading