in reply to Test::Harness bug ? ... or author idiocy ?

print goes to STDOUT, and warn goes to STDERR. The text on STDOUT is parsed as TAP. So if one of your many printf() happened to print text to STDOUT that could be interpreted as unsuccessful TAP (or just inject content into the stream of valid TAP that breaks its syntax), then this could be a legitimate failure. Afaik, STDERR is always seen as logging data and never parsed as TAP. Anything your script writes to STDOUT should be prefixed with a "# " to ensure it can't be parsed as TAP. Don't forget if your printf wraps lines, each line would need to begin with "# ". In general you should just remove any printing to STDOUT in your XS code. Is there any reason to use printf instead of warn for diagnostics?

Replies are listed 'Best First'.
Re^2: Test::Harness bug ? ... or author idiocy ?
by syphilis (Archbishop) on Nov 06, 2021 at 06:55 UTC
    Is there any reason to use printf instead of warn for diagnostics?

    If I use warn then it gets output to the screen every time it gets executed in make test - creating a deluge of noise to sift through.
    If I use printf then I can quietly fiddle about with pieces of code and see what's going on, and then not be slugged with the deluge if I run make test.
    To that extent, it's working perfectly ... the only problem is that TAP::Harness likes to give me misleading messages that I don't really understand.

    It's just a practice I engage in as a convenience thing during debugging, and such printf statements are not something that I'll (intentionally ;-) include in a CPAN release.
    I don't regard this TAP::Harness behaviour as a big issue ... but I'm a little curious about it.

    Cheers,
    Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom