Assertion failure while building WeeChat 2.7 #50
Comments
|
Are you using the latest commit on branch master? It seems that i can not reproduce the issue... And that output buffer is dynamically allocated indeed: Lines 376 to 382 in ece94b7 Only the input buffer: Line 151 in ece94b7 If it's caused by an older version, maybe we should consider a new release. If change the size of this input buffer helps, it's another thing. Update: I noticed one thing, when i print Update2: OK, i got it.... a pretty annoying problem.. |
maybe we should just allocate that dynamically to 8KB on start and double its size whenever necessary (with realloc, so contents stay available). note there's also convbuf, which must be 4x as big as line. dalias suggested to maybe use |
|
But later i noticed some other "bugs". Specifically, three cases(GNU handle them smoothly): That is, po files are not to be parsed line by line. Though, we have not met such po files. The third one is most terrible one, because poparser assumes only one space after an entry token, not zero, not two or more, not tab, exactly one space. So i want it to parse po files token by token. As a result, we should be able to feed the parser arbitrarily. And that will also solves this issue. Since it does not matter how you feed the parser anymore. While the structure of |
this is one reason of #50. One line is generally short, and [8192] is big enough for our usage. But after cmake invokes msgmerge, lines are joined. So we printf some super long lines into po files. And again, cmake invokes msgfmt to use these updated po files. So we meet these super long lines.
this is one reason of #50. One line is generally short, and [8192] is big enough for our usage. But after cmake invokes msgmerge, lines are joined. So we printf some super long lines into po files. And again, cmake invokes msgfmt to use these updated po files. So we meet these super long lines.
|
@awilfox Can you try the commit just before the msgmerge commit on branch Reason why msgfmt failed is that msgmerge printed some super long lines. The latest commit fixed msgmerge, previous commits made some improves on msgfmt itself. So either the latest commit or commits before it should fix this specific issue. Though i could generate mo files for all .po in weechat2.7. But that does not mean it's correct and it will pass all other packages on all platforms. It will be nice if you could test it with other common packages. This will not be merged into master so soon, since it's changed a lot... @rofl0r And maybe we should release a new tarball after the merge. |
oh, good find! was it because of
|
Nope... But msgfmt should have the ability to process super long lines too, IMO. And parsing po files token by token solves those "bugs". But also you can feed arbitrary strings to it due to its working mechanism. That makes msgfmt more robust than it ever been. I think it's ok as it does not add much code. Most of the time, i was moving codes around. The logic is:
|
|
i can see the benefit of making parser more robust, otoh a big rewrite like this probably introduces some new bugs... |
|
Great. That's also my concern. It needs sometime to fix bugs. Do i need to force push so that msgmerge fix is the first new commit, then pr. Or we just patch and push to the master? |
i guess we can just fix master directly |
this is the cause of #50. One line is generally short, and [8192] is big enough for our usage. But after cmake invokes msgmerge, lines are joined. So we printf some super long lines into po files. And again, cmake invokes msgfmt to use these updated po files. So we meet these super long lines.
this is one reason of #50. One line is generally short, and [8192] is big enough for our usage. But after cmake invokes msgmerge, lines are joined. So we printf some super long lines into po files. And again, cmake invokes msgfmt to use these updated po files. So we meet these super long lines.
|
cool, thanks! so the new stragegy is to simply use a separate string for chunks of 1024 in input string (as in msgstr "foo" "bar" "baz" ) ? (i expected there was another bug that lead to the string becoming too long)
as you see fit, thanks |
Backtrace:
This seems to be caused by the line being longer than the statically-allocated buffer:
Is it possible to use dynamic allocation for reading lines?
The text was updated successfully, but these errors were encountered: