"Jeffrey C Honig" wrote: >If I read RFC0822 correctly field-name does not have a length limit, >it's one or more characters. Given that, using a fixed value of NAMESZ >in m_getfld() is an invalid assumption.
2822 says that lines MUST be no longer than 998 characters, and gives no way to break a field-name across multiple lines. So as far as I can tell you shouldn't ever get a field-name longer than 998 chars. (The field-body may be wrapped, but that's not important right now.) >The proper fix would involve a dynamically allocated buffer and an >examination of all uses of m_getfld() to update it. > >A quick look shows that most of the calls to m_getfld() define name char >name[NAMSZ] and pass it to m_getfld(). If they don't assume a length, a >quick change to m_getfld() to return a pointer to a buffer and >reallocate it as necessary should only take a hour or two. Urgh. All the body-text uses of m_getfld() work on the model of 'pass it a buffer and get the next chunk of text; call it again to get the next bit'. It'd be difficult to make the change you propose without affecting that. I'm very leery about changes to m_getfld(), especially since we don't currently have any test cases for all the different things it has to do (including interaction with stdio buffer endings and so on). I personally would rather avoid major changes to it until we have some decent tests to detect accidental breakage. I certainly don't think this particular reliance on a hard-coded buffer size (of which nmh has many) justifies fiddling with m_getfld() without a safety net^W^Wtest suite. -- PMM _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
