use of "t" (text) flag for fopen in X.Org

Jon TURNEY jon.turney at dronecode.org.uk
Fri Aug 29 07:05:17 PDT 2014


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 <matthieu-rOhiHPjUwFY at public.gmane.org>
> 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.



More information about the xorg-devel mailing list