Closed Bug 402395 Opened 12 years ago Closed 12 years ago

Dangling semi-colon caused when "ac_add_options --disable-logging" throws warning in VS2005

Categories

(Core :: Networking: Cookies, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9beta1

People

(Reporter: masmullin, Assigned: masayuki)

References

Details

Attachments

(2 files, 2 obsolete files)

Attached file quick hack to get the build going (obsolete) —
Trunk build on windows vs2005 breaks when "ac_add_options --disable-logging" is used in a mozconfig

When PR_LOGGING is not defined, the COOKIE_LOGSTRING macro is mapped to nothing (line 328); thus line 437 has a dangling semi-colon when PR_LOGGING is not defined.  VS2005 throws a warning for dangling semi-colons, and the build treats warnings as errors.
Attached patch More long term patch (obsolete) — Splinter Review
Attachment #287276 - Attachment is obsolete: true
Attachment #287277 - Attachment is obsolete: true
Comment on attachment 287281 [details] [diff] [review]
Real patch (previous one had bug)

This patch fixes a problem similar to the one fixed in bug 260209.  The patch in that bug used the "do{}while(0)" trick, whereas this patch uses a simpler trick.
Attachment #287281 - Flags: superreview?(benjamin)
Attachment #287281 - Flags: review?(dougt)
Assignee: nobody → masmullin
Component: Build Config → Networking: Cookies
Product: Firefox → Core
QA Contact: build.config → networking.cookies
OS: Windows XP → All
Hardware: PC → All
Duplicate of this bug: 402506
Why don't you use PR_BEGIN_MACRO and PR_END_MACRO like my patch in bug 402506?
Attached patch proposal patchSplinter Review
proposal patch, using PR_BEGIN_MACRO and PR_END_MACRO.
Attachment #287377 - Flags: superreview?(benjamin)
Attachment #287377 - Flags: review?(dougt)
Blocks: 401998
Flags: blocking1.9?
Target Milestone: --- → mozilla1.9 M9
I think that "0;" is about as simple as you can get to solve this problem, and I tried to be simple.

However, it seems like the "PR_BEGIN_MACRO /* nothing */ PR_END_MACRO" is the norm to solve this problem in the moz-code.
(In reply to comment #5)
> Why don't you use PR_BEGIN_MACRO and PR_END_MACRO like my patch in bug 402506?

Why is that better than using 0? Using 0 seems simpler.
PR_BEGIN_MACRO/PR_END_MACRO hack is already used, so, it is safety on all our supporting platforms. If "0;" is better, we should use it on other similar points.
Comment on attachment 287281 [details] [diff] [review]
Real patch (previous one had bug)

The other one is better
Attachment #287281 - Flags: superreview?(benjamin)
Attachment #287281 - Flags: superreview-
Attachment #287281 - Flags: review?(dougt)
bsmedberg recommends that we don't block beta on this, moving TM out to
"undefined", I'll let the component owner make the final blocking call.

(blocking? w/TM=M9 is asking for beta-blocking status)
Target Milestone: mozilla1.9 M9 → ---
Attachment #287377 - Flags: superreview?(benjamin)
Attachment #287377 - Flags: superreview+
Attachment #287377 - Flags: review?(dwitte)
Attachment #287377 - Flags: review?(dougt)
Attachment #287377 - Flags: review?(dwitte) → review+
Comment on attachment 287377 [details] [diff] [review]
proposal patch

a=beltzner for M9
Attachment #287377 - Flags: approvalM9+
Assignee: masmullin → masayuki
checked in for M9. thanks for the patches!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Flags: blocking1.9?
Target Milestone: --- → mozilla1.9 M9
You need to log in before you can comment on or make changes to this bug.