Re: [Hampshire] scanf conversion - anyone know what '%m' is?

>> I've just raised a bug against a RH package because it uses the %m
>> format
>> conversion, which doesn't exist according to everything I've found. The
>> response I got is that it's a poorly-documented extension...
>
> As a note for the future it would be really useful if you could provide
> more information with this sort of query.

Really? I thought that would just be extraneous here; I'm not filing a bug
report with HantsLUG, I filed it with RH...

> What package are you talking about, where in the code have you spotted
> this problem.

OK - it's in frysk-0.0.1.2008.03.19.rh1-1.el5.src.rpm, and the failure
happens at line 135 of frysk-imports/elfutils/tests/line2addr.c. You get
an "unknown conversion type character" error. The error does not occur
with frysk-0.0.1.2007.06.21.rh2-4.el5.src.rpm, which builds properly.

> You see "code like this" doesn't help us identify the package and access
> how important portability is and the impact this could have on whether
> extensions should be used.

Nor was it intended to - I was just trying to find out what %m does to see
if this was something that needed fixing in my build environment, or
something that needed fixing in the RH package. It turned out to be
both...

> Anyway. I know of no use of %m with scanf() are you sure it was scanf() ?

It was actually sscanf() - but I'm not aware of any important differences
between those (other than the obvious, of course).

> %m has two documented uses for output that I'm aware of.
>
> First it is the format string marker for syslog() where it marks the
> point to include the output of strerror(errno). See "man 3 syslog" and
> I believe POSIX.1

It's not that.

> Secondly it's use for the same function in printf() in the GNU C library
> has been documented as a GNU extension in the GNU C Library Reference
> Manual since at least 1993.

It might be that - despite Peter's help, I still haven't actually worked
out what the code is trying to do yet. Nor do I expect I will, since
that's not actually going to change anything.

> So if it's reasonable that the package in question is only ever going
> to be used/built on systems with the GNU library then the use of the
> extension is okay. If it's targeted at non-GNU environments such as
> embedded systems then the use of the extension should be investigated.

Perhaps - but is this list really the context in which that should happen?

Vic.