Marking 3405 as verified. Yanking out John & Simon's comments into a separate bug, so that Steve can fix or punt as appropriate. " ------- Additional Comments From mcmullen@netscape.com 03/05/99 11:50 ------- Great. But two things: 1. There are three files called mactime.c in the tree. One of them is in NSPR, and is in use. 2. It's "daylight-saving time". (It's not a man-eatings tiger, but a man-eating tiger, see). ------- Additional Comments From sfraser@netscape.com 03/05/99 11:59 ------- Yeah, and kudos to the person who #defined an existing routine name to something else. That's always a bad idea. The real fix for this problem would have been to change that #define. "

I am not clear on what this bug is. elig, can you put in a better summary line? And info in this bug on what exactly this it?

Probably because I'm not clear on what the bug is, either. ;) E-mailed sfraser to request clarification on what was meant by the comments in bug 3405.

This bug (and my comments in 3405) is about a dangerous coding practice, that could cause problems in future if #include patterns change. That practice is redefining an existing function name to something else, like #define ctime MacCTime because there is always the danger the the macros will be expanded incorrectly, and you end up calling yourself recursively (as happened last week). The right thing to do is redefine the symbol on all platforms, or to do the ctime messing in NSStdLib, where conflicts are unlikely.

Is there a specific instance of this practice that this bug seeks to fix, and is it a blocker for M3?

in xp_mcom.h: #define XP_TIME() GetTimeMac() #define time(t) Mactime(t) #define gmtime(t) Macgmtime(t) #define mktime(t) Macmktime(t) #define ctime(t) Macctime(t) #define localtime(t) Maclocaltime(t) No, this isn't needed for M3, but don't blame me if it comes back to bite us later.

Not a must fix for M4.

Updated the summary as it isn't a platform parity issue, just a bad coding practice than needs to be rectified. Pushing back to M8 to get it out of my hair while I address feature work I need to get done.

Note: this came back to bite us in bug # 4357 (broken FTP).

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.

mass-moving all m12 bugs to m13

can this bug closed ? last comment in this bug : Peter Trudelle 1999-11-02 15:05

(18 month pause) Why, yes it can be closed.