Repository navigation
Enclosing middleware fails for certain content #452
Description
Describe the bug
https://bibtexparser.readthedocs.io/en/main/customize.html#default-parse-stack says that there is Enclosing middleware used, likely to make sure no illegal characters exist in fields.
Reproducing
Version: 2.0.0b2
Note the abstract of the following excerpt (The 396$\{2}$ chip is):
Bibtex:
@Article{Konstadinidis2009,
author = {Konstadinidis, Georgios K. and Tremblay, Marc and Chaudhry, Shailender and Rashid, Mamun and Lai, Peter F. and Otaguro, Yukio and Orginos, Yannis and Parampalli, Sudhendra and Steigerwald, Mark and Gundala, Shriram and Pyapali, Rambabu and Rarick, Leonard D. and Elkin, Ilyas and Ge, Yuefei and Parulkar, Ishwar},
title = {Architecture and physical implementation of a third generation 65 nm, 16 Core, 32 thread chip-multithreading SPARC processor},
date = {2009-01-01},
doi = {10.1109/JSSC.2008.2007144},
abstract = {This third-generation Chip-Multithreading (CMT) SPARC processor consists of 16 cores with shared memory architecture and supports a total of 32 main threads plus 32 scout threads. It is targeted for high-performance servers, and is optimized for both single- and multi-threaded applications. The 396$\{2}$ chip is fabricated in an 11 metal layer 65-nm CMOS process and operates at a nominal frequency of 2.3 GHz, consuming a maximum power of 250 W at 1.2 V. This paper provides an overview of the architectural highlights and describes the physical implementation challenges and solutions including circuit innovations in memory arrays, register files, and floating-point hardware that boost the performance and circuit robustness with low area overhead. © 2006 IEEE.},
author_keywords = {Arrays; Chip multi-threading (CMT); Clocking; Computer architecture; Execute ahead; Hardware scout; Microprocessor; Multi-core; Multi-threaded; Power management; Register files; SerDes; SPARC architecture; Transactional memory}
}
Workaround
Manually looking for the problematic character
Remaining Questions (Optional)
Please tick all that apply:
- I would be willing to contribute a PR to fix this issue.
- This issue is a blocker, I'd be grateful for an early fix.
Activity
claell commentedon Jan 25, 2024
This gives me an error when parsing the file (written from bibtexparser):
So, not sure whether the problem is with writing or reading.
MiWeiss commentedon Jan 25, 2024
There seems to be some confusion about the meaning of the EnclosingMiddleware, which has the purpose of removing the
{}or"which are potentially wrapping field values.E.g.
{Konstadinidis, Georgios K. and Tremblay, Marc}becomesKonstadinidis, Georgios K. and Tremblay, MarcYou may want to try the follow wrappers around a well-known latex en-/decoding library which allows many if not most usecases:
claell commentedon Jan 26, 2024
Ah, alright. I didn't find documentation on this, so I misinterpreted the purpose of that Middleware.
So, regarding my issue: I think there is some check for the sanity of field values? Right now, I can write fields with said value, but when I read a file with that value, I get a parsing error.
I think, this should not happen. And right now, I need to use a manual workaround for the specific problematic (invalid) field value content.
claell commentedon Jul 16, 2026
I revisited this with a stricter regression: current main can return a normal entry while silently dropping every field after the escaped-brace sequence. Draft PR #572 contains the focused splitter fix and a parse/write/reparse assertion for the later fields.