Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | dmake throws exception | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Build Tools | Reporter: | quetschke | ||||||||||
Component: | code | Assignee: | quetschke | ||||||||||
Status: | CLOSED FIXED | QA Contact: | issues@tools <issues> | ||||||||||
Severity: | Trivial | ||||||||||||
Priority: | P3 | CC: | issues | ||||||||||
Version: | 644 | ||||||||||||
Target Milestone: | OOo 1.1 Beta2 | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Windows 2000 | ||||||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||||||
Developer Difficulty: | --- | ||||||||||||
Attachments: |
|
Description
quetschke
2003-01-24 11:17:57 UTC
Created attachment 4421 [details]
Picture of thrown exception
I build a debug version of dmake and found that in line 58 of dmake/tempnam.c: strcpy(dir, getenv(TempPath[n])); strcpy sometimes tries to copy the NULL pointer. This fails for MSVC. The following patch fixes this. Created attachment 4422 [details]
Patch for dmake/tempnam.c
applied in cws_ooo_so branch, to be integrated on mws644 soon. Ooops. The patch is not wrong, but I had a discussion on IRC with Ken who pointed out that the real problem is the: #define tempnam dtempnam line in: dmake/win95/microsft/config.h tempnam is defined and working in MSVC 6.0, I was just at the moment adding a new patch for dmake to this IZ. It removes the usage tempnam.c for the MSVC build. My first patch is only a sanity check for strcpy, this one is the "real" fix. At the moment a OO643C build with a dmake without tempnam.c is running. Created attachment 4424 [details]
"Real" patch for dmake
verified. The patch committed to cws_srx644_cws_ooo_so and mws_srx644 needs the following fix: --- tools/dmake/tempnam.c 2003/01/31 17:47:16 1.1.1.1.46.2 +++ tools/dmake/tempnam.c 2003/01/31 23:38:01 1.1.1.1.46.3 @@ -72,7 +72,7 @@ /* ret_val = new char[i+2 /* '\0' & '\\' *//* + 8 /*root*//* + 4 /*.ext*//*];*/ if (ret_val) { - strncpy(ret_val,dir, sizeof(retval)-1); + strncpy(ret_val,dir, sizeof(ret_val)-1); /* Make sure directory ends with a separator */ #if defined(DOS) || defined(PM2) || defined(WIN) || defined(WNT) @@ -109,7 +109,7 @@ #if defined(OS2) || defined(WIN) || defined(WNT) || defined(DOS) itoa(nTemp,ret_val + i,26); #else - snprintf(ret_val+i, sizeof(retval) + i, "%03u", nTemp); + snprintf(ret_val+i, sizeof(ret_val) + i, "%03u", nTemp); #endif strcat(ret_val,ext); nhandle = _open( ret_val, _O_CREAT | _O_EXCL, _S_IWRITE | _S_IREAD ); It looks as if tempnam.c is only used for the MSVC build, but it doesn't have to. Look at dmake_2.diff Please apply and close this issue. I checked in the following patch dmake_msc.diff. It consists of the part approved by Ken plus a few changes to make dmake builable with MSVC in the cws_srx644_ooo20030223 branch. I don't close the issue because I still think the dmake_2.diff is the correct way to fix this problem. As MSVC has the tempnam function we should use this library function and not the extra dtempnam version. Volker (I will remove the 11319 dependency because works the way it is) Created attachment 4686 [details]
Fix tempnam and make dmake buildable with MSVC
vq->mh: OK to apply the "Real" patch (dmake_2.diff) to cws_srx644_00020030309? I did a full build without tempnam.c, using the internal MSVC version and it build as usual. (In fact the CC=cl.exe ./configure && make) build version also doesn't use dempnam.c) I think this issue can be closed after that. mh->vq: go ahead. Committed dmake_2.diff to cws_srx644_ooo20030309. Closing issue ... works close |