Hello Petr,
On 8/30/19 11:06 AM, Petr Mladek wrote:
> On Thu 2019-08-29 19:39:45, Uwe Kleine-König wrote:
>> On 8/29/19 11:09 AM, Rasmus Villemoes wrote:
>>> On 29/08/2019 10.27, Juergen Gross wrote:
>>>> Hmm, what about already existing format strings conatining "%dE"?
>>>>
>>>> Yes, I could find only one (drivers/staging/speakup/speakup_bns.c), but
>>>> nevertheless...
>>>
>>> Indeed, Uwe still needs to respond to how he wants to handle that. I
>>
>> This is indeed bad and I didn't expect that. I just took a quick look
>> and this string is indeed used as sprintf format string.
>
> Hmm, it seems that solving this might be pretty tricky.
I thought about this and we could make it possible by some syntax. Such that
someint = 42
pr_info("%d}E\n", someint)
emits
42E
(I'm open to use a different "end-of-fmt-specifier" char, a } might
confuse source editors when highlighting matching braces. Maybe '#'?
This idea could be transferred to %p, too, which then lift the
limitation that some strings cannot easily be produced by printk et al.
(Of course this makes the format string parsing still more complicated
which I expect you won't like.) This would make it possible then to
adapt drivers/staging/speakup/speakup_bns.c before introducing the
format for error ints.
> I see this as a warning that we should not play with fire.
> There might be a reason why all format modifiers are put
> between % and the format identifier.
AFAIK they are put after the format specifier in the kernel to still be
able to benefit from the compiler's printf attribute.
>>> still prefer making it %pE, both because it's easier to convert integers
>>> to ERR_PTRs than having to worry about the type of PTR_ERR() being long
>>> and not int, and because alphanumerics after %p have been ignored for a
>>> long time (10 years?) whether or not those characters have been
>>> recognized as a %p extension, so nobody relies on %pE putting an E after
>>> the %p output. It also keeps the non-standard extensions in the same
>>> "namespace", so to speak.
>>
>>> Oh, 'E' is taken, well, make it 'e' then.
>>
>> I like having %pe to print error valued pointers. Then maybe we could
>> have both %de for ints and %pe for pointers. :-)
>
> I would prefer to avoid %pe. It would make sense only when the value
> really contains error id.
The same holds true for %dE. Something has to happen if an int is passed
that isn't an error code. I'm emitting it as is in my patch, the same
could be done for a pointer.
> It means that it has to be used as:
>
> if (IS_ERR(p)) {
> pr_warn(...);
>
> The error path might handle the error using PTR_ERR() also
> on other locations. Also PTR_ERR() will make it clear that we
> are trying to print the error code.
I suggest to postpone this until we have %dE. (But I consider using %de
instead as then if we later chose that %pe is a nice idea they can use
the same modifier.)
Best regards
Uwe
Attachment:
signature.asc
Description: OpenPGP digital signature
