My Neutrino implementation of scanf and its children such as sscanf can not handle the "%X" argument but handles the "%x" just fine. I can not find any documentation saying %X is valid all my C and C++ books only talk about %x so far this is causing us problems in modules/libpref/src/prefapi.c but I think it is broken in other places in the code as well.

lets assign this one to mcmullen to get the ball rolling. the only way to get these kind of global changes factored in to the work of each module owner is to: -do the greping|searching of the entire tree. ( http://lxr.mozilla.org is a good tool for this...) -find all instances of problems -create bugs or a tracking document of all the areas that need fixing. -communicate the global problem. -follow up on tracking the tasks to completion. I can help with the later stages by I'll need help up front to get the first set of tasks off the ground.

So hex on neutrino is required to be in ransom-note form: 00a234e7? instead of 00A234E7? OK, we'll have to write our own scanner, then.

I don't understand, I don't think writing a new scanner is neccessary. I just tested the neutrino scanf if I use %x it will correctly read in upper and lower case hex numbers. When I use printf %x prints with lower case hex and %X prints with upper case. The problem is %X just doesn't work, QNX considers it a bug and will fix it but they also say its a low priority bug because the "standard" does not define what %X should do.

John, what's the right thing to do here? Is this our bug?

Yes one case of this is my bug (in nsPersistentFileDescriptor). And it sounds as though changing %X to %x is all that is required. Leave this bug open. We're moving all the file stuff as part of the xpcom2.0 whompage. This can easily be fixed after that.

Accepting

Somebody seems to have fixed this case. Should this bug get closed, or is it to become an ever-morphing bug that moves from line to line in the source tree? :-)

No, its still in the original place that I reported: modules/libpref/src/prefapi.c I have changed it on my local copy from %X to %x and things seem to work as well as they did. Not sure if its been changed in all the other places that need it.

John says this is now fixed.

Bulk moving to XPCOM, in preparation for removal of XP File Handling component. (XPFH has received two bugs in ~5 months, and is no longer in active use.)