From: "Henrik Rydberg" <rydberg@euromail.se>
To: Chase Douglas <chasedouglas@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] Input: Add EVIOC mechanism for MT slots
Date: Sun, 5 Feb 2012 08:59:06 +0100 [thread overview]
Message-ID: <20120205075906.GA7698@polaris.bitmath.org> (raw)
In-Reply-To: <4F2D7730.3090704@gmail.com>
> > This is resolved on the preprocessor level, so C99 or not does not
> > enter the problem. Compile-time constant, as you can see in the code
> > example in the patch summary.
>
> You're right, I didn't catch that. It will be compatible with all C
> compilers if you use a static number of slots.
Yes, but this statement is merely repeating something that has been
true since the sixties.
> However, it will break if you use a non-C99 C compiler and the code
> wants to do dynamic number of slots calculations.
Of course, which is why C99 cannot be used for portable code. And it
still has nothing to do with this patch.
> I imagine most callers would do:
>
> EVIOCGABS call on ABS_MT_SLOT;
> int num_slots = ABS_MT_SLOT.max - ABS_MT_SLOT.min
> struct INPUT_MT_REQUEST(num_slots) req;
Besides leaving a possible giant stack crash in your code, it assumes
memory is somehow magically allocated. Not good practise in low-level
programming. You wouldn't use a template this way, would you?
> This will break on non-C99 C compilers and other language compilers.
Of course, since you use the C99 dynamic stack construct, which,
again, is not portable.
> It also will lead to head-scratcher bugs when someone compiles it
> just fine in their C99 project, copies the code to another project
> with a different compiler, and is confronted with the issue.
No, since people how know C do not do things like that.
> I think this issue should be enough to rethink the interface.
No, since your issues with C99 has nothing to do with this patch.
Henrik
next prev parent reply other threads:[~2012-02-05 7:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 19:00 [PATCH v3] Input: Add EVIOC mechanism for MT slots Henrik Rydberg
2012-02-03 0:05 ` Chase Douglas
2012-02-03 7:27 ` Henrik Rydberg
2012-02-04 18:21 ` Chase Douglas
2012-02-05 7:59 ` Henrik Rydberg [this message]
2012-02-05 17:13 ` Chase Douglas
2012-02-05 19:40 ` Henrik Rydberg
2012-02-05 22:55 ` Chase Douglas
2012-02-06 7:25 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120205075906.GA7698@polaris.bitmath.org \
--to=rydberg@euromail.se \
--cc=chasedouglas@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.