bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bison-1.875: build feedback


From: Paul Eggert
Subject: Re: bison-1.875: build feedback
Date: Fri, 3 Jan 2003 13:52:30 -0800

> Date: Fri, 3 Jan 2003 13:20:23 -0700 (MST)
> From: "Nelson H. F. Beebe" <address@hidden>
> 
> Because library functions, including abort() and exit(), can be
> redefined by users in the C and C++ programming languages,

I don't know about C++, but that is not true for Standard C.  Standard
C users are not allowed to redefine 'abort' or 'exit'.  All
identifiers with external linkage in the Standard C library are
reserved for use as identifiers with external linkage.

Perhaps in your implementation users are allowed to redefine 'abort'
as an extension to Standard C, and the compiler is warning us about
that possibility.  But I think it's more likely that your compiler
just doesn't know about 'abort'.  Perhaps a future version will know,
or perhaps there's an option that you can give it to tell it that
it can assume that 'abort' cannot return.


> For the function in question in bitset.c, one might rewrite it to
> something like the immediately-preceding bitset_bytes() function that
> avoids the question of whether abort() returns by moving the return
> statements outside the switch statement.

True, but for bitset_bytes some other non-abort()-aware compiler might
complain that 'bytes' is being used without being initialized.  So I
don't think this kind of solution will work in general.  Besides, I
find the style in bitset_bytes inferior to that of bitset_init: it's
harder to read.  I'd rather change away from the style used in
bitset_bytes.


> If abort() is used a lot this way, then a wrapper function, e.g.,
> bison_abort(), could be used to reduce the warning instances to just
> one, with an echo statement before the compilation output to notify
> the user that any such complaint is harmless.

I don't offhand see how such a wrapper function would work.  If we did
this:

   int
   int_bison_abort (void)
   {
     abort ();
     return 0;
   }

and use "return int_bison_abort ();", this will work only for
functions that return 'int', and we'd need a separate wrapper function
for each returned type.  Also, this solution will cause a warning for
compilers that know that abort does not return.  And we'd need to tell
GCC that int_bison_abort does not return.

Here's another possibility:

   #if ! COMPILER_KNOWS_ABOUT_ABORT
   # undef abort
   # define abort() do {} while (1)
   #endif

This would be better, since the existing abort code wouldn't have to
be rewritten to use int_bison_abort.  But it has some obvious
drawbacks of its own.

I suspect that all of these cures may be worse than the disease, which
is only a minor sniffle anyway.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]