[sane-devel] [Janitorial] Zero(!) compiler warnings

Olaf Meeuwissen paddy-hack at member.fsf.org
Sat Sep 24 07:46:08 UTC 2016

ABC writes:

> On Thu, Sep 22, 2016 at 11:09:03PM +0900, Olaf Meeuwissen wrote:
>> > To what mktemp() should be replaced? Will there be sanei function to
>> > drop-in replace it?
>> The mktemp(3) manual page suggests mkstemp (POSIX.1-2001, not in C99).
>> That is used by the bh and pieusb backends.  You can also use tmpfile
>> (POSIX.1-2001, POSI.1-2008 and in C99), which is what I used in my patch
>> for the avision backend (not pushed yet).
> I feared that mkstemp and tmpfile are not available on all platforms 
> supported by sane-backends.

In that case, maintainers of such platforms should speak up.  I know
there are quite a few platforms that were supported at some point in
time but I have no idea what is still actively maintained and/or used.

The tmpfile() function is part of C99 which seems reasonably portable,
to me at least.  FTR, we made that the default around the end of 2015,
beginning 2016.

>> I wasn't thinking of providing a sanei function for this.
> I think, if many libc authors wasn't able to design and implement good
> enough mktemp() from the first attempt, how is average sane contributor
> could be expected to do better? Just saying 'do not use mktemp' can
> produce even worse results (see below).

The problem with mktemp() is with its API specification.  There's is
nothing you can do about that now.  The C library implementers cannot
provide a secure mktemp().  To rectify that tmpfile() and mkstemp() were

>> Note that mktemp() only creates a file*name* so the O_EXCL is not an
>> issue then and calling fopen() or open() isn't subject to this flag
>> unless passed explicitly.  Child processes inherit non-exclusive open
>> file descriptors.
> Main security problem with mktemp is chance of opening precreated file,
> which impact could be mitigated with open() with O_EXCL flag. (Or
> fopen() with "x" flag, but I don't know how portable it's again.) In
> that regard, mktemp() can not be worse than opening static filename,
> like pieusb_specific.c, avision.c, canon630u-common.c, pnm.c,
> xerox_mfp.c are currently doing.

Opening a static filename may be just as bad, depending on how that name
is created and what that file is used for.  But that is not something a
compiler or linker can warn about, unfortunately.  For that we need to
rely on eagle eyes such as yours ;-) and the patches that produces.

# That is, personally I am mostly targetting the "low-hanging fruit",
# the kind of issues that can be detected by tools and fixed with not
# too much effort or knowledge of each specific backend.  The mktemp()
# warnings actually require a bit of understanding of the backend in
# order to fix.
# I'm just the janitor.  I'll look after the building (sane-project)
# but the tenants (backend maintainers) will have to look after their
# own rooms (backends).

Hope this helps,
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join

More information about the sane-devel mailing list