Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86486
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Never use strncpy! |
| Date | 2022-09-22 09:32 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <tgh333$233l1$1@dont-email.me> (permalink) |
| References | (2 earlier) <tgf3l1$1qu51$3@dont-email.me> <tgfh5a$1s7n1$1@dont-email.me> <tgfhrv$1s8i7$1@dont-email.me> <tgfus6$1tinp$1@dont-email.me> <tggtkr$10rd$1@gioia.aioe.org> |
On 22/09/2022 07:59, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> If you use "volatile" when you mean "atomic", your code is wrong.
>
> Yeah. Some programmers might have mistakenly thought that 'volatile'
> means the same thing as "atomic", and thus "thread-safe". However,
> programmers who know what they are doing also know that it isn't
> anything like that.
>
> I think that the exact semantics of 'volatile' might be largely
> implementation-defined, but AFAIK in most if not all compilers
> (especially gcc and clang) it effectively acts as an optimization
> barrier. It tells the compiler "any access to this must never be
> optimized away, nor moved to happen somewhere else in the code".
Yes. You can think of "volatile" as telling the compiler "there are
things you don't know about that mean you can't apply as-if
optimisations here".
The implementation-defined nature of volatile accesses is unavoidable.
If you have, say, a volatile write to a uint32_t variable then most
32-bit or 64-bit systems will implement it as a single write. A 16-bit
system will have to break it into two writes. An original Alpha would
do a 64-bit read, a modify, then a 64-bit write. Most systems will
attempt a single write even if the address is unaligned, others might
break it down or the hardware might cause a trap on the unaligned
access. Accesses to bitfields have multiple possible implementations.
All in all, there's a lot that can't be specified in the standards.
Then there are read-write-modify accesses such as "v++;" or "v |=
0x0100;". Some architectures can do these atomically, others would need
bus locks and interrupt disabling to be atomic.
(As an interesting aside here, in the C standards up to C17 only
described "access to volatile objects". Only in C17 did it change to
"volatile accesses", defining what was meant by using a
pointer-to-volatile cast to access data that had not been defined as
volatile. I don't know what the C++ standards say there - but I believe
that, as for C, every compiler handles volatile accesses as you might
expect.)
>
> In other words, if you eg. write a loop where you read a
> 'volatile' ten times, then the compiler must generate code that
> reads it ten times, inside that exact loop and nowhere else.
> The compiler must not optimize it to one single read or
> completely away (because it doesn't see anything changing it).
It can still unroll the loop. Similarly if you have :
volatile int v;
if (a) {
v = 1;
} else {
v = 2;
}
then the compiler can do:
int temp = a ? 1 : 2;
v = temp;
The run-time pattern of volatile accesses must match the "abstract
machine" exactly, but the pattern of the generated assembly need not.
>
> By far the most common (perhaps only) use of this is in embedded
> programming, especially on very small processors, where things
> like ports and CPU pins are mapped into RAM (which means that
> reading the same memory location may give different values at
> different times, and writing values there most definitely must
> never be optimized away).
Yes.
And for single-core processors (covering the great majority of
small-systems embedded programming), "volatile" is often sufficient in
many places where atomics would be needed in general. But you need to
be aware of its limitations here - it forms part of the solution, but
not necessarily all of it. (The gcc implementation of C11/C++11
atomics, at least in the gcc versions I have looked at, are dangerously
wrong for single core embedded systems.)
>
> There's another useful use of 'volatile': In benchmarking.
> Run the code that's to be benchmarked, and then assign the
> return value to a volatile. This stops the compiler from
> optimizing the whole thing away because it sees that the
> result isn't being used for anything. (It might not have
> optimized it away in the first place, but assigning the
> result to a volatile makes sure of that.)
Yes, that kind of use is convenient. You also have to ensure that the
calculation depends on a volatile variable, not just that the result is
written to one. It gives you a more self-contained test than reading an
starting input from the command line and printf'ing the result.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-21 10:04 +0000
Re: Never use strncpy! "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-09-21 15:06 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 15:24 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 15:30 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 19:20 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 19:33 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 23:14 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-22 04:40 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 08:56 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-22 12:02 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-23 13:23 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 13:49 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-23 15:25 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 16:03 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-23 14:34 +0000
Re: Never use strncpy! Michael S <already5chosen@yahoo.com> - 2022-09-23 08:19 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-23 17:57 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 18:36 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 16:22 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 16:25 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 17:09 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 17:14 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-26 17:34 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 07:53 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-26 10:21 +0200
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:34 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-26 13:39 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-26 17:47 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-27 14:17 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-27 18:07 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-27 12:42 -0700
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-28 09:32 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-28 13:34 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 21:11 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-01 06:26 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-10-01 17:01 +0000
Re: Never use strncpy! Michael S <already5chosen@yahoo.com> - 2022-10-02 15:32 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-10-03 14:01 +0000
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-03 13:49 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 12:46 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 04:14 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:43 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:48 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 04:53 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:58 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 08:27 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-03 13:49 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-04 10:53 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 12:44 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 05:59 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 09:32 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 15:42 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 18:10 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 16:19 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 18:27 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-23 14:47 +0000
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-21 16:12 +0000
Re: Never use strncpy! Philipp Klaus Krause <pkk@spth.de> - 2022-09-23 19:52 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 16:25 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-21 14:00 +0000
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:03 +0000
Re: Never use strncpy! Philipp Klaus Krause <pkk@spth.de> - 2022-09-23 19:50 +0200
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 07:54 +0000
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-21 15:56 +0100
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 15:36 +0000
Re: Never use strncpy! Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-09-21 08:59 -0700
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-21 13:23 -0700
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-21 21:49 +0100
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-21 19:18 -0400
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 00:39 +0100
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-21 20:45 -0400
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 18:00 -0700
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 17:55 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:09 +0000
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-22 11:44 -0700
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-22 23:33 -0400
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-22 19:00 -0700
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-22 19:04 -0700
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-22 22:49 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 11:38 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-24 09:43 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 11:59 +0200
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-24 06:27 -0400
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-24 11:53 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 20:58 +0200
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 16:01 -0700
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 09:37 +0200
Re: Never use strncpy! Manfred <noname@add.invalid> - 2022-10-01 01:24 +0200
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-30 16:43 -0700
Re: Never use strncpy! Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-22 21:03 -0500
csiph-web