[illumen]

I don't apologise for him, or defend him. However, I do have some insight into what may have caused this unsettling behaviour.

The bug report does not follow the projects standard for reporting bugs.

The main problem is that it does not link to the specification, and explain why it is not up to spec. This is required by the glibc bug reporting standards.

Later the reporter checks the scanf function against another implementation, as is asked for by the glibc documentation. Later the reporter also explains why it is wrong against the specification. If the reporter had read the guidelines initially and done these things, that would have been an acceptable bug report. To not do so is wasting the maintainers time. It is rude if the reporter knew about the bug reporting guidelines, and decided to waste the maintainers time anyway.

In this particular case, I think the reporter and the maintainer could have done a better job.

[tptacek]

You don't need the spec to see that "0xz" doesn't match "%x%c". The man page for scanf is sufficient, as is having read K&R. This is extremely basic C standard library stuff; it's not an odd corner case.

[illumen]

Sure. A good maintainer would see that, and perhaps ask politely for the missing required information.

That's the main job of a good open source maintainer really. Asking for people to provide more information, test cases, and documentation.

In this case, the maintainer queried the behaviour (in a rude way granted), and was not sure why it was wrong. All that attitude from the maintainer was definitely not needed.

If someone reports a bug to your project, make them feel welcome! Numerous times, I've seen these single bug reporter people turn into long time contributors. All it takes is a bit of attention, giving them credit, and providing a nice environment for them.

Anyway, it's good there is a much more functional team heading glibc these days.