Bug 177830 - urandom dummy function breaks builds
urandom dummy function breaks builds
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: flex (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Petr Machata
:
: 177813 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-14 22:26 EST by Jonathan S. Shapiro
Modified: 2015-05-04 21:32 EDT (History)
2 users (show)

See Also:
Fixed In Version: FC-4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-25 11:34:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix for warnings and missing std::cerr's emitted with -d (3.29 KB, patch)
2006-01-15 12:20 EST, Jonathan S. Shapiro
no flags Details | Diff
Revised spec file with license update (5.23 KB, text/plain)
2006-01-15 12:21 EST, Jonathan S. Shapiro
no flags Details

  None (edit)
Description Jonathan S. Shapiro 2006-01-14 22:26:41 EST
In some very recent update of flex, somebody decided to introduce a randomly
generated function name that references yy_flex_realloc() in order to suppress
some irritating warnings. For example, in one of my lexers the static dummy
function reads:

/* Some people want warning-free code, and under certain #define
   conditions, gcc will warn for unusedness of some functions.  This
   function is provided merely to silent these warnings.  It's not
   static itself, so it will clutter exports, but it has at least
   urandom name so that clashes won't occur.*/
void _yy_dummy_uses_of_static_functions_b2f4_517d_02ff_b30c_3e5a_47d7_aaa3_3b5d_()
{
  yy_flex_realloc ((void*)0, 0);
}


This is a fine idea, except that whoever did it didn't initialize the random
number generator properly. The result is that I get the same function WITH THE
SAME RANDOM DIGITS every time I execute flex. In consequence, programs with
multiple lexers in them no longer link because of the multiply defined symbol.

This "feature" either needs to be removed or repaired. Until it is repaired,
flex should be reverted to a version that doesn't have this "feature".
Comment 1 Jonathan S. Shapiro 2006-01-14 22:56:55 EST
Okay. I have looked at the source. Contrary to the comment, urandom isn't called
at all. This is a statically introduced name in the skeleton file that
absolutely cannot be exported this way. Petr just didn't quite think this patch
through properly.

If the goal is to suppress warnings from GCC, it might make more sense to use
attributes indicating that the procedure may be unused and no warning should be
emitted. These, of course, need to be conditionalized according to whether GCC
is in use.

Also, while I have Petr's attention, the correction on use of cerr incorporated
in this patch is not complete. There are a bunch of references to cerr that are
emitted from gen.c. These should be prefixed with std:: as well.
Comment 2 Jonathan S. Shapiro 2006-01-15 12:19:28 EST
Petr doesn't seem to be working this weekend. I need to get some things done and
I can't wait on this, so I fixed it myself.

The attached patch is relative to flex-2.5.4a-35.fc4. I have removed Petr's
dummy function from the skeleton file and replaced it with a conditionalized
__attribute__() attached to the declaration of yy_flex_realloc(). This attribute
is added *only* when compiling with GCC (because other compilers don't grok the
attribute extension). It uses the __attribute__() form so that the qualifier
will work even when compiling with --std=xxx. It is possible (indeed, it is is
likely) that other functions will need to have YY_MAY_BE_UNUSED added to their
declarations. I have not attempted an exhaustive search for them -- my priority
was simply to get flex working again.

This patch also updates gen.c to appropriately convert "cerr" to "std::cerr" in
the diagnostics that are generated for debugging code. It is mildly surprising
that these weren't included in Petr's patch, since they were easy enough to find
with grep.

All that is needed is to install the current flex source rpm, add the patch in
the obvious places, and update the version number. I have sufficient IP rights
to make this patch public, and I hereby jointly assign it to RedHat (which
should be good enough, since my "commit" on this note is an electronic
signature, but contact me if you need more). While you are tinkering with the
SPEC file, please update the license to GPL (it currently says BSD, which is
wrong) and you can then close
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115354 and also the one I
filed about the license being wrong (which isn't showing up in the bug list yet).

For those who need an immediate fix, you can pull an updated RPM from the
Coyotos repository at http://srl.cs.jhu.edu/YUM/coyotos/4/i386. This version
will be supersceded automatically when Petr releases the official fix, so you
should be able to "install and forget." The source RPM can be found at
http://srl.cs.jhu.edu/YUM/coyotos/SRPMS/
Comment 3 Jonathan S. Shapiro 2006-01-15 12:20:51 EST
Created attachment 123219 [details]
Fix for warnings and missing std::cerr's emitted with -d
Comment 4 Jonathan S. Shapiro 2006-01-15 12:21:44 EST
Created attachment 123220 [details]
Revised spec file with license update

You will certainly want to change the version number!
Comment 5 Petr Machata 2006-01-18 05:03:55 EST
Hm, exactly... I realized that the patch is nonsense at the weekend, and I hoped
nobody would crash on it until I get around to fix it properly. My bad.
Comment 6 Fedora Update System 2006-01-18 10:30:55 EST
From User-Agent: XML-RPC

flex-2.5.4a-36.fc4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 7 Petr Machata 2006-01-18 11:25:08 EST
*** Bug 177813 has been marked as a duplicate of this bug. ***
Comment 8 Petr Machata 2006-01-20 09:42:32 EST
It is already pushed for final, so hopefully in a couple of hours. There is
fixed version in testing already, if it is the option for you.
Comment 9 Jonathan S. Shapiro 2006-01-20 16:05:00 EST
The push came through, and I confirm the fix. This bug can be closed.

Nice to see that my patch was useful, and your edit of the comment above
YY_MAY_BE_UNUSED was a good call.

Also, for anybody who pulled my binary RPM in desperation, I have also confirmed
that this update correctly replaces my temporary fix.
Comment 10 Petr Machata 2006-01-25 11:34:42 EST
Thanks for the help, Jonathan. I'm closing the bug.

Note You need to log in before you can comment on or make changes to this bug.