Re: ctermid: return string literal, document MT-Safety pitfall

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 14, 2014, Florian Weimer <fweimer@redhat.com> wrote:

> I've been staring at the standard for a while.  The standard
> explicitly refuses to deal with the interaction of signal handlers and
> threads

The argument doesn't require threads, they'd be a distraction at best.

The issue is whether a signal handler that interrupts strcpy (or memcpy,
or any other standard function) could observe effects in the destination
string (or whatever else they modify) that are not specified in the
definition of the corresponding function.

Say, given:

char foo[5] = "12";

int main() {
  signal (SIGUSR1, checkme)
  strcpy (&foo[1], "23");
}

what standard-compliant values can checkme legitimately expect to find
in foo[0], foo[1], foo[2], foo[3], and foo[4]?

Under my reading, foo[0] and foo[4] could only hold '1' and '\0',
respectively, since nothing allows strcpy to modify them from their
initial values.  foo[1] and foo[3] could only hold '2' and '\0',
respectively, since they already held the values that the standard says
strcpy should store in them.  foo[2] could hold '\0' or '3' (*),
depending on whether the the signal interrupts strcpy before or after it
gets to it.  I reason that temporarily storing alternate values in the
destination would be as much of a deviation from the specification as
writing to foo[0] or foo[4].

(*) or perhaps other intermediate values, if chars are too big to copy
as a single memory transaction, so that narrower memory blocks, such as
individual bits, had to be copied one at a time.

I realize this reading would rule out not only the potentially useful
practice of resetting full cache lines instead of loading them from
memory before overwriting them, but also other possibilities that would
arguably comply with the current specification if it was limited to pre-
and post-condition only, without any observable intermediate results,
such as repeatedly generating random strings and comparing them with the
source until they were identical, or incrementing the source as an
multi-byte unsigned number, represented by the concatenation of all the
bits in the destination string, until it compares equal to the source.
These other possibilities would not only fail the efficiency
expectations, but also produce visible intermediate results that IMHO
are not allowed by the current wording of the standard.  But see below.

> I very much doubt the intent was invalidate existing implementations
> which write ghost values

This was the sort of argument that made me revisit my understanding that
strcpy et al couldn't âwrite garbageâ in the destination before writing
the final value.  I still don't see how the current wording would allow
for that, but now I agree it would make perfect sense to have wording in
standards that would allow this sort of behavior.

Maybe not arbitrary garbage, certainly not temporarily writing garbage
to other user-visible portions of the address space, but something that
can be construed as executing an algorithm that, starting with the
destination assumed to contain random garbage, makes progress towards
the goal of having the destination hold a copy of the source.

Similar wording could apply to qsort too, although to inspect
intermediate qsort results you don't even need signal handlers: it calls
back the compare function synchronously, and the compare function is not
prohibited from accessing the array being sorted; plus, I believe
numerous qsort implementations have historically exchanged array entries
as sorting progresses, so attemting to rule that out would be unlikely
to fly.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer