After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724002 - gtkdoc-scan: Fix use of uninitialised value in trace logging
gtkdoc-scan: Fix use of uninitialised value in trace logging
Status: RESOLVED FIXED
Product: gtk-doc
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: 1.20
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-10 08:26 UTC by Philip Withnall
Modified: 2014-02-10 09:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtkdoc-scan: Fix use of uninitialised value in trace logging (1.68 KB, patch)
2014-02-10 08:26 UTC, Philip Withnall
committed Details | Review
gtkdoc-scan: Fix use of uninitialised value in trace logging (1.69 KB, patch)
2014-02-10 09:13 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
committed Details | Review

Description Philip Withnall 2014-02-10 08:26:43 UTC
Patch attached.
Comment 1 Philip Withnall 2014-02-10 08:26:45 UTC
Created attachment 268639 [details] [review]
gtkdoc-scan: Fix use of uninitialised value in trace logging

Fixes:
> Use of uninitialized value $6 in concatenation (.) or string at
> /opt/gnome3/build/bin/gtkdoc-scan line 552, <INPUT> line X.

This was caused by re-using the numbered match variables from one regexp
after running another regexp.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2014-02-10 09:13:49 UTC
The following fix has been pushed:
d511ebc gtkdoc-scan: Fix use of uninitialised value in trace logging
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2014-02-10 09:13:56 UTC
Created attachment 268646 [details] [review]
gtkdoc-scan: Fix use of uninitialised value in trace logging

Fixes:
> Use of uninitialized value $6 in concatenation (.) or string at
> /opt/gnome3/build/bin/gtkdoc-scan line 552, <INPUT> line X.

This was caused by re-using the numbered match variables from one regexp
after running another regexp.