On 27/08/2014 09:02, Matthieu Herrb wrote:
one of the OpenBSD developers recently tried to add some consistency
checks on the "mode" argument to fopen(3), based on the ISO C and
POSIX standards. Thus his code rejects the "t" flag.
In the whole X.Org code base it seems to be used inconsistently. Only
libXfont seems to set this flag unconditionally.
If windows libs can support read Unix text files without this flag,
the patch below could be applied, and moreover we should set a policy
somewhere in the developers' wiki to tell to never add it. or if it's
I think this policy is just that that some level of POSIX is assumed
(for things which aren't under _WIN32)
Strictly, this seems to me a rather restrictive interpretation of the
standard. [1] says that the mode string *begins* with one of the listed
sequences, so 'r' followed by any old garbage is valid :-)
[1] http://pubs.opengroup.org/onlinepubs/007908799/xsh/fopen.html
needed to decide if it should be added for all text files
unconditionally or inside some CPP conditionals for the system(s) that
need it.
From 81f4ba7ba72c08077bc3a0618e7b0e4eb533c9e6 Mon Sep 17 00:00:00 2001
From: Matthieu Herrb <[email protected]>
Date: Wed, 27 Aug 2014 09:44:03 +0200
Subject: [patch libXfont] Remove "t" flag from fopen() calls.
This is the only place in the whole X.Org set of packages where this
flag is used, leading us to think it's not useful here either.
OpenBSD is considering adding some more sanity checks on fopen mode
argument and this "t" causes the new code to fail fopen().
This seems to have been added as part of Win32 porting in commit dd695cb6.
I agree that it doesn't seem like it should be needed, but maybe Colin
can confirm.
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
