vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Magnus Hagander <magnus@hagander.net> writes: >> Andrew Dunstan <andrew@dunslane.net> writes: >>> For now I'm going try to fix it by changing it to: >>> next unless $pieces[0] =~/^[A-F0-9]{3}$/; > Yeah, nice catch. Wouldn't surprise me if we actually had this problem > before, just that the dropped symbols were not actually used by our own > modules. I notice the export count jumped to 5226... I was wondering where the count would go. It strikes me that the pattern needs to be {3,} or maybe just +. I dunno what this column is measuring, but if we are past 0xA00 then surely 0x1000 is not far away. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |
| |||
| Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > >>> Andrew Dunstan <andrew@dunslane.net> writes: >>> >>>> For now I'm going try to fix it by changing it to: >>>> next unless $pieces[0] =~/^[A-F0-9]{3}$/; >>>> > > >> Yeah, nice catch. Wouldn't surprise me if we actually had this problem >> before, just that the dropped symbols were not actually used by our own >> modules. I notice the export count jumped to 5226... >> > > I was wondering where the count would go. > > It strikes me that the pattern needs to be {3,} or maybe just +. > I dunno what this column is measuring, but if we are past 0xA00 > then surely 0x1000 is not far away. > > http://msdn2.microsoft.com/en-us/lib...85(VS.71).aspx appears to suggest that the size of the field is fixed. But who knows? cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org |
| |||
| Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> It strikes me that the pattern needs to be {3,} or maybe just +. >> I dunno what this column is measuring, but if we are past 0xA00 >> then surely 0x1000 is not far away. > http://msdn2.microsoft.com/en-us/lib...85(VS.71).aspx appears to > suggest that the size of the field is fixed. That would imply that dumpbin fails at 4096 symbols per file. While I surely wouldn't put it past M$ to have put in such a limitation, I think it's more likely that the documentation is badly written. In any case it would be easy enough to make up a quick test to see what happens with say void func1() {} void func2() {} ... void func5000() {} regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org |
| |||
| > http://msdn2.microsoft.com/en-us/lib...85(VS.71).aspx > appears to > > suggest that the size of the field is fixed. > > That would imply that dumpbin fails at 4096 symbols per file. While I > surely wouldn't put it past M$ to have put in such a > limitation, I think > it's more likely that the documentation is badly written. Yes, it starts with 3 and goes to 4 digits above FFF Andreas ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org |
| ||||
| Zeugswetter Andreas ADI SD wrote: >> http://msdn2.microsoft.com/en-us/lib...85(VS.71).aspx >> appears to >> >>> suggest that the size of the field is fixed. >>> >> That would imply that dumpbin fails at 4096 symbols per file. While I >> surely wouldn't put it past M$ to have put in such a >> limitation, I think >> it's more likely that the documentation is badly written. >> > > Yes, it starts with 3 and goes to 4 digits above FFF > OK, then {3,} is the right quantification. Will fix. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |