%% Markus Mauhart <[EMAIL PROTECTED]> writes: mm> 1) first the minor buggy
mm> if (ebuf->bufnext > ebuf->bufstart + ebuf->size) mm> return -1; mm> ... if ebuf->size is really malloc'ed size, then this must be ... mm> if (ebuf->bufnext >= ebuf->bufstart + ebuf->size) mm> return -1; mm> ... otherwise the later loop could read outside the allocated memory. Yes, but this can never happen because each string _must_ be nul-terminated, and the previous invocation before the last one would set: ebuf->bufnext = p+1; (where p points to the nul char) so ebuf->bufnext can never, really, equal the last character in the string; it will always be one greater than that. However, it's not a good practice to rely on this "action at a distance" so I'll make this change. mm> 2) the while loop, which AFAICS should iterate over all mm> EOL-terminated substrings until it finds an EOL that is not mm> escaped with odd-numbered backslash, counts all backslashes in mm> that substrings, instead of only the neighbours of EOL. Yes, this is definitely not right. mm> 3) regardless of the mentioned wrong BS EOL detection, the loop mm> will never really loop, cause after the 1st run it still sits at mm> the 1st EOL, hence the 2nd run will find zero BS before the old mm> EOL and therefore break without reading anything new. Yes, this is definitely wrong as well. I'll fix these. Strangely, no one has ever reported a problem that could be related to these bugs. I guess most people don't end up using multiline backslash escaped strings with eval. The only way to do it would be within a define/endef because all other uses would have the backslash/newline already removed before the eval gets the string. I suppose most people aren't using eval to handle entire rules. mm> And btw, the "return 0" looks a bit surprising too. No, that's correct. This function is only called during an eval and nothing should be added to the line counter during an eval. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make