Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #151145
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: memcpy can't take null. |
| Date | 2020-04-06 18:46 +0200 |
| Organization | solani.org |
| Message-ID | <r6fmcn$f4r$1@solani.org> (permalink) |
| References | <6c3de07e-15c8-4cc0-a805-636a5976d086@googlegroups.com> <dbb91496-3624-477c-92b7-f1d8ff434193@googlegroups.com> <1CpiG.149251$Pj7.50779@fx14.iad> |
Am 05.04.20 um 20:39 schrieb Richard Damon: > This lack of standardization of behavior is a historical artifact that > K&R didn't define what to do here, and when the first Standard was being > written, both options were is common usage, so rather than break > existing implementations, it was left undefined. It is of course fairly > trivial to make a wrapper to provide the alternate behavior if you > really need it as described above. The next C standard will even make realloc for zero size undefined behaviour. Too many implementations didn't conform with the old C11 standard for zero size realloc. C17 thus allowed more implementation-defined behaviour, but at that point it wasn't very useable for portable programs anymore. So it will just be undefined behaviour in C2X.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
memcpy can't take null. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 06:47 -0700
Re: memcpy can't take null. Öö Tiib <ootiib@hot.ee> - 2020-04-05 07:30 -0700
Re: memcpy can't take null. Richard Damon <Richard@Damon-Family.org> - 2020-04-05 14:39 -0400
Re: memcpy can't take null. Philipp Klaus Krause <pkk@spth.de> - 2020-04-06 18:46 +0200
Re: memcpy can't take null. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 12:45 -0700
Re: memcpy can't take null. Philipp Klaus Krause <pkk@spth.de> - 2020-04-07 07:28 +0200
Re: memcpy can't take null. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-05 16:00 -0700
Re: memcpy can't take null. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-05 18:29 -0600
Re: memcpy can't take null. scott@slp53.sl.home (Scott Lurndal) - 2020-04-06 18:08 +0000
Re: memcpy can't take null. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-06 15:44 -0600
Re: memcpy can't take null. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 13:54 -0700
Re: memcpy can't take null. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 14:30 -0700
Re: memcpy can't take null. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 01:20 +0100
Re: memcpy can't take null. Siri Cruise <chine.bleu@yahoo.com> - 2020-04-05 19:09 -0700
Re: memcpy can't take null. Guillaume <message@bottle.org> - 2020-04-07 16:50 +0200
Re: memcpy can't take null. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 09:19 -0700
Re: memcpy can't take null. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 09:21 -0700
Re: memcpy can't take null. Guillaume <message@bottle.org> - 2020-04-08 01:41 +0200
Re: memcpy can't take null. scott@slp53.sl.home (Scott Lurndal) - 2020-04-08 00:30 +0000
Re: memcpy can't take null. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 02:06 -0700
Re: memcpy can't take null. Richard Damon <Richard@Damon-Family.org> - 2020-04-08 09:17 -0400
Re: memcpy can't take null. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:16 -0700
Re: memcpy can't take null. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-08 13:33 -0700
Re: memcpy can't take null. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 09:05 -0700
Re: memcpy can't take null. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-09 13:28 -0700
Re: memcpy can't take null. richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-04-09 23:41 +0000
Re: memcpy can't take null. Guillaume <message@bottle.org> - 2020-04-08 16:17 +0200
Re: memcpy can't take null. Ike Naar <ike@sdf.lonestar.org> - 2020-04-07 22:01 +0000
Re: memcpy can't take null. Guillaume <message@bottle.org> - 2020-04-08 01:32 +0200
csiph-web