Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #94806 > unrolled thread

UB of memcpy(NULL, NULL, 0)

Back to article view | Back to comp.lang.c

Contents

  UB of memcpy(NULL, NULL, 0) Noob <root@127.0.0.1> - 2016-10-13 12:42 +0200
    Re: UB of memcpy(NULL, NULL, 0) Richard Heathfield <rjh@cpax.org.uk> - 2016-10-13 11:55 +0100
      Re: UB of memcpy(NULL, NULL, 0) Noob <root@127.0.0.1> - 2016-10-13 13:09 +0200
        Re: UB of memcpy(NULL, NULL, 0) Richard Heathfield <rjh@cpax.org.uk> - 2016-10-13 12:22 +0100
          Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-13 12:22 -0700
            Re: UB of memcpy(NULL, NULL, 0) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-13 12:32 -0700
              Re: UB of memcpy(NULL, NULL, 0) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-13 12:34 -0700
      Re: UB of memcpy(NULL, NULL, 0) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-10-13 08:24 -0600
        Re: UB of memcpy(NULL, NULL, 0) Richard Heathfield <rjh@cpax.org.uk> - 2016-10-13 16:22 +0100
        Re: UB of memcpy(NULL, NULL, 0) Noob <root@127.0.0.1> - 2016-10-13 17:49 +0200
          Re: UB of memcpy(NULL, NULL, 0) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-10-13 12:02 -0600
    Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-15 20:56 +0200
      Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-15 12:52 -0700
      Re: UB of memcpy(NULL, NULL, 0) "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-15 15:55 -0400
      Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-15 13:41 -0700
        Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-16 11:17 +0200
          Re: UB of memcpy(NULL, NULL, 0) Richard Heathfield <rjh@cpax.org.uk> - 2016-10-16 10:26 +0100
          Re: UB of memcpy(NULL, NULL, 0) raltbos@xs4all.nl (Richard Bos) - 2016-10-16 09:55 +0000
            Re: UB of memcpy(NULL, NULL, 0) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-16 08:44 -0400
              Re: UB of memcpy(NULL, NULL, 0) David Brown <david.brown@hesbynett.no> - 2016-10-17 10:06 +0200
                Re: UB of memcpy(NULL, NULL, 0) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 09:06 -0400
                  Re: UB of memcpy(NULL, NULL, 0) David Brown <david.brown@hesbynett.no> - 2016-10-17 16:29 +0200
                    Re: UB of memcpy(NULL, NULL, 0) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 17:05 -0400
                      Re: UB of memcpy(NULL, NULL, 0) David Brown <david.brown@hesbynett.no> - 2016-10-18 11:19 +0200
                        Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-18 08:04 -0700
                        Re: UB of memcpy(NULL, NULL, 0) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-18 16:27 -0400
              Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-17 08:59 -0700
                Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-17 11:21 -0700
                  Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-17 13:42 -0700
                    Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-17 14:46 -0700
                      Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-17 15:52 -0700
                        Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-17 16:43 -0700
                          Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-18 08:00 -0700
                            Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-18 09:14 -0700
                              Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-18 09:43 -0700
                                Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-18 11:31 -0700
                                  Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-18 12:49 -0700
                                Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-18 12:03 -0700
                Re: UB of memcpy(NULL, NULL, 0) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 17:06 -0400
                  Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-17 14:55 -0700
          Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-16 11:23 -0700
        Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-17 08:49 -0700
          Re: UB of memcpy(NULL, NULL, 0) raltbos@xs4all.nl (Richard Bos) - 2016-10-18 16:54 +0000
            Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-18 11:09 -0700
              Re: UB of memcpy(NULL, NULL, 0) raltbos@xs4all.nl (Richard Bos) - 2016-10-23 13:24 +0000
                Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-24 09:28 -0700
                Re: UB of memcpy(NULL, NULL, 0) <william@wilbur.25thandClement.com> - 2016-10-29 11:32 -0700
                  Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-29 14:12 -0700
      Re: UB of memcpy(NULL, NULL, 0) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-15 22:00 +0100
        Re: UB of memcpy(NULL, NULL, 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 02:51 -0700
          Re: UB of memcpy(NULL, NULL, 0) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-16 11:20 +0100
            Re: UB of memcpy(NULL, NULL, 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 04:14 -0700
              Re: UB of memcpy(NULL, NULL, 0) BartC <bc@freeuk.com> - 2016-10-16 12:22 +0100
              Re: UB of memcpy(NULL, NULL, 0) Richard Heathfield <rjh@cpax.org.uk> - 2016-10-16 13:01 +0100
                Re: UB of memcpy(NULL, NULL, 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 05:29 -0700
                  Re: UB of memcpy(NULL, NULL, 0) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-16 20:47 +0100
                    Re: UB of memcpy(NULL, NULL, 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-17 02:08 -0700
                  Re: UB of memcpy(NULL, NULL, 0) David Brown <david.brown@hesbynett.no> - 2016-10-17 10:24 +0200
                    Re: UB of memcpy(NULL, NULL, 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-17 08:05 -0700
                      Re: UB of memcpy(NULL, NULL, 0) David Brown <david.brown@hesbynett.no> - 2016-10-17 17:25 +0200
    Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-17 17:08 +0200
      Re: UB of memcpy(NULL, NULL, 0) Lorinczy Zsigmond <zsiga@nospam.for.me> - 2016-10-21 12:46 +0200
        Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-21 08:06 -0700
          Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-21 18:30 +0200
            Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-21 09:34 -0700
              Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-22 07:42 +0200
                Re: UB of memcpy(NULL, NULL, 0) James Kuyper <jameskuyper@verizon.net> - 2016-10-22 10:31 -0400
                  Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-22 17:49 +0200
                    Re: UB of memcpy(NULL, NULL, 0) Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-22 13:43 -0700
                      Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-23 07:47 +0200
                        Re: UB of memcpy(NULL, NULL, 0) "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 11:07 -0400
                          Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-23 17:45 +0200
                            Re: UB of memcpy(NULL, NULL, 0) "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 12:16 -0400
                            Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-24 07:38 -0700
                              Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-24 08:38 -0700
                                Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-24 09:44 -0700
                        Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-23 12:22 -0700
                          Re: UB of memcpy(NULL, NULL, 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-23 13:37 -0700
                            Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-23 14:15 -0700
                            Re: UB of memcpy(NULL, NULL, 0) Ike Naar <ike@iceland.freeshell.org> - 2016-10-24 06:11 +0000
                              Re: UB of memcpy(NULL, NULL, 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-24 00:58 -0700
                        Re: UB of memcpy(NULL, NULL, 0) Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-23 14:07 -0700
                      Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-24 07:48 -0700
                        Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-24 08:40 -0700
                          Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-24 10:03 -0700
                            Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-24 12:06 -0700
                              Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-24 13:36 -0700
                                Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-24 13:57 -0700
                        Re: UB of memcpy(NULL, NULL, 0) Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-24 14:16 -0700
                          Re: UB of memcpy(NULL, NULL, 0) supercat@casperkitty.com - 2016-10-24 17:23 -0700
                            Re: UB of memcpy(NULL, NULL, 0) Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-25 07:57 -0700
                    Re: UB of memcpy(NULL, NULL, 0) James Kuyper <jameskuyper@verizon.net> - 2016-10-22 18:23 -0400
                  Re: UB of memcpy(NULL, NULL, 0) "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 10:44 -0400
                    Re: UB of memcpy(NULL, NULL, 0) Richard Heathfield <rjh@cpax.org.uk> - 2016-10-23 16:24 +0100
                      Re: Verbing Noob <root@127.0.0.1> - 2016-10-23 18:02 +0200
          Re: UB of memcpy(NULL, NULL, 0) raltbos@xs4all.nl (Richard Bos) - 2016-10-23 13:26 +0000
            Re: UB of memcpy(NULL, NULL, 0) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-23 07:40 -0700
        Re: UB of memcpy(NULL, NULL, 0) asetofsymbols@gmail.com - 2016-10-21 23:56 -0700
          Re: UB of memcpy(NULL, NULL, 0) Lőrinczy Zsigmond <nospam@for.me> - 2016-10-22 12:21 +0200
            Re: UB of memcpy(NULL, NULL, 0) Keith Thompson <kst-u@mib.org> - 2016-10-22 16:33 -0700

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#95220

On Monday, October 24, 2016 at 7:11:59 AM UTC+1, Ike Naar wrote:
> On 2016-10-23, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> > On Sunday, October 23, 2016 at 8:21:43 PM UTC+1, Keith Thompson wrote:
> >>
> >> Meanwhile, any remaining problems can be avoided simply by *not*
> >> passing null pointers to memcpy().  The effort needed to do this is
> >> nonexistent in most cases, and minimal in all other cases.
> >> 
> >>
> > /*
> >   It is possible for a company to have zero employees, but it's
> >   highly unusual.
> > */
> > void foo(Employee *e, int Nemployees)
> > {
> >   Employee *s = malloc(N * sizeof(Employee));
> >   
> >   memcpy(s, e, N * sizeof(Employee));
> > }
> >
> > That's the snag. This bug will lurk and could pop up at any
> > inconvenient moment for reasons which are hard to understand,
> > eg the malloc() implementation changes.
> 
> Which bug are you talking about?
> - the use of N instead of Nemployees?
> - not checking whether s is a null pointer when calling memcpy
> - not checking whether e is a null pointer when calling memcpy
> - having a memory leak (the result of malloc leaks when foo returns)
>
N instead of Nemployees will come out at first compile.

The function will of course do something and not leak memory, it's
just a quick fragment. Though to be fair putting in leak and allocation
failure detection would actually have solved the problem, at risk
of creating another one. If s is null because Nemployees is zero,
the program might report "out of memory" when in fact, due to some
unusual circumstances which hardly ever apply, it's being asked to
run a null payroll and submit tax data for nil employees.

 

[toc] | [prev] | [next] | [standalone]

#95204

Lorinczy Zsigmond <nospam@for.me> writes:

> How to resolve this?  It is not possible,
> it cannot be resolved;
> the standard is out, so libc-implementors
> and compiler-writer are allowed to do
> tricks I don't like, but are legal
> according to the standard.
> (see the original post)
>
> Also there is no point in changing the standard,
> or fix this in later versions,
> it would only increase the chaos.

My question was meant as a hypothetical, ie, suppose the question
had come up while the original Standard was in the process of
being written.  But it seems like you aren't really interested,
so no matter.

[toc] | [prev] | [next] | [standalone]

#95226

On Saturday, October 22, 2016 at 3:44:05 PM UTC-5, Tim Rentsch wrote:
> If the "more well-defined" point of view were adopted, then
> everyone would be forced to pay the price for that, whether
> they want to or not.

What price?

There is no circumstance in which complying with a requirement that using
memcpy with size zero must be an unconditional nop would require a compiler
to generate more than one extra comparison in any defined case, and cases
where even that would be required would be exceptionally rare and unlikely
to occur outside of contrived scenarios.

By contrast, situations in which the an operand (especially the source)
might be null when the size is zero occur fairly often when implementing
some APIs, and handling them in accordance with the present standard would
require that programmers add comparisons in source code which will not be
needed in the executable code, but which compilers may not be able to
optimize out.

Note, btw, that if someone is actually interested in optimization, adding
a directive to indicate that a certain argument will be ignored in all
cases where some other argument is zero would allow a compiler to save
a load instruction when generating code like foo(somePtr, size) in cases
where it can determine [likely while in-lining the enclosing function]
that "size" will be zero.  Easy optimization for a compiler to make, but
if memcpy doesn't offer such a guarantee no code which calls it will be
able to do so either except by adding a superfluous comparison.

[toc] | [prev] | [next] | [standalone]

#95228

supercat@casperkitty.com writes:
[...]
> Note, btw, that if someone is actually interested in optimization, adding
> a directive to indicate that a certain argument will be ignored in all
> cases where some other argument is zero would allow a compiler to save
> a load instruction when generating code like foo(somePtr, size) in cases
> where it can determine [likely while in-lining the enclosing function]
> that "size" will be zero.  Easy optimization for a compiler to make, but
> if memcpy doesn't offer such a guarantee no code which calls it will be
> able to do so either except by adding a superfluous comparison.

What would such a directive look like?  You've proposed a lot of
annotations to let programmers convey extra information to the
compiler.  I'd like to know just how much clutter your proposals would
add to the language.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#95235

On Monday, October 24, 2016 at 10:40:17 AM UTC-5, Keith Thompson wrote:
> supercat writes:
> > Note, btw, that if someone is actually interested in optimization, adding
> > a directive to indicate that a certain argument will be ignored in all
> > cases where some other argument is zero would allow a compiler to save
> > a load instruction when generating code like foo(somePtr, size) in cases
> > where it can determine [likely while in-lining the enclosing function]
> > that "size" will be zero.  Easy optimization for a compiler to make, but
> > if memcpy doesn't offer such a guarantee no code which calls it will be
> > able to do so either except by adding a superfluous comparison.
> 
> What would such a directive look like?  You've proposed a lot of
> annotations to let programmers convey extra information to the
> compiler.  I'd like to know just how much clutter your proposals would
> add to the language.

I'm not sure the best balance between versatility, complexity of
implementation, and compatibility with existing compilers, but as a first
go something like:

    void *make_object(
      int cmd,
      int arg1,
      __PtrAndSize( void *dat, int size) );

Where __PtrAndSize(x,y) was defined as a macro that would expand to
something equivalent to (x,y) except that if y is zero, the caller would
be free to pass anything that isn't a trap representation for x.  I think
code which used that directive macro could be made compatible with existing
compilers by simply adding:

#ifndef __PtrAndSize
#define __PtrAndSize(x,y) x,y
#endif

Nice and simple.  Alternatively, if an implementation defines __UNSPECIFIED
as a macro chained to an intrinsic that could be passed to a function, a
caller could pass __UNSPECIFIED,0 for the pointer and size if the called
function was specified to ignore the pointer when the size is zero.  I think
some compilers already support __UNSPECIFIED, so defining the behavior of
memcpy(any,__UNSPECIFIED,0) would allow code to be made more efficient when
using the already-existing feature of such compilers.

[toc] | [prev] | [next] | [standalone]

#95238

supercat@casperkitty.com writes:
> On Monday, October 24, 2016 at 10:40:17 AM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > Note, btw, that if someone is actually interested in optimization, adding
>> > a directive to indicate that a certain argument will be ignored in all
>> > cases where some other argument is zero would allow a compiler to save
>> > a load instruction when generating code like foo(somePtr, size) in cases
>> > where it can determine [likely while in-lining the enclosing function]
>> > that "size" will be zero.  Easy optimization for a compiler to make, but
>> > if memcpy doesn't offer such a guarantee no code which calls it will be
>> > able to do so either except by adding a superfluous comparison.
>> 
>> What would such a directive look like?  You've proposed a lot of
>> annotations to let programmers convey extra information to the
>> compiler.  I'd like to know just how much clutter your proposals would
>> add to the language.
>
> I'm not sure the best balance between versatility, complexity of
> implementation, and compatibility with existing compilers, but as a first
> go something like:
>
>     void *make_object(
>       int cmd,
>       int arg1,
>       __PtrAndSize( void *dat, int size) );
>
> Where __PtrAndSize(x,y) was defined as a macro that would expand to
> something equivalent to (x,y) except that if y is zero, the caller would
> be free to pass anything that isn't a trap representation for x.  I think
> code which used that directive macro could be made compatible with existing
> compilers by simply adding:
>
> #ifndef __PtrAndSize
> #define __PtrAndSize(x,y) x,y
> #endif
>
> Nice and simple.  Alternatively, if an implementation defines __UNSPECIFIED
> as a macro chained to an intrinsic that could be passed to a function, a
> caller could pass __UNSPECIFIED,0 for the pointer and size if the called
> function was specified to ignore the pointer when the size is zero.  I think
> some compilers already support __UNSPECIFIED, so defining the behavior of
> memcpy(any,__UNSPECIFIED,0) would allow code to be made more efficient when
> using the already-existing feature of such compilers.

So your annotations would be implemented as macros with reserved names.

How many such macros would you want to add to the language?  How much
bigger would the standard document have to be to describe them all?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#95245

On Monday, October 24, 2016 at 2:05:09 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > On Monday, October 24, 2016 at 10:40:17 AM UTC-5, Keith Thompson wrote:
> >> supercat writes:
> >> > Note, btw, that if someone is actually interested in optimization, adding
> >> > a directive to indicate that a certain argument will be ignored in all
> >> > cases where some other argument is zero would allow a compiler to save
> >> > a load instruction when generating code like foo(somePtr, size) in cases
> >> > where it can determine [likely while in-lining the enclosing function]
> >> > that "size" will be zero.  Easy optimization for a compiler to make, but
> >> > if memcpy doesn't offer such a guarantee no code which calls it will be
> >> > able to do so either except by adding a superfluous comparison.
> >> 
> >> What would such a directive look like?  You've proposed a lot of
> >> annotations to let programmers convey extra information to the
> >> compiler.  I'd like to know just how much clutter your proposals would
> >> add to the language.
> >
> > I'm not sure the best balance between versatility, complexity of
> > implementation, and compatibility with existing compilers, but as a first
> > go something like:
> >
> >     void *make_object(
> >       int cmd,
> >       int arg1,
> >       __PtrAndSize( void *dat, int size) );
> >
> > Where __PtrAndSize(x,y) was defined as a macro that would expand to
> > something equivalent to (x,y) except that if y is zero, the caller would
> > be free to pass anything that isn't a trap representation for x.  I think
> > code which used that directive macro could be made compatible with existing
> > compilers by simply adding:
> >
> > #ifndef __PtrAndSize
> > #define __PtrAndSize(x,y) x,y
> > #endif
> >
> > Nice and simple.  Alternatively, if an implementation defines __UNSPECIFIED
> > as a macro chained to an intrinsic that could be passed to a function, a
> > caller could pass __UNSPECIFIED,0 for the pointer and size if the called
> > function was specified to ignore the pointer when the size is zero.  I think
> > some compilers already support __UNSPECIFIED, so defining the behavior of
> > memcpy(any,__UNSPECIFIED,0) would allow code to be made more efficient when
> > using the already-existing feature of such compilers.
> 
> So your annotations would be implemented as macros with reserved names.

Most of the things I would add to the language would be macros with
reserved names; some of them would not require compilers to do anything
but would invite them to make certain optimizing assumptions if their
authors see fit to do so.  Others would require that implementations
either promise to uphold behavioral guarantees that many implementations
naturally uphold anyway, or else refuse compilation.  A few would require
that implementations reject programs if they can't uphold guarantees
beyond what most implementations today can support, but would make it
possible to define a class of programs which all implementations would
be required to either run without UB or reject entirely [e.g. directives
via which a programmer could indicate that a certain function will never
be called recursively beyond a certain nesting level would make it possible
for an implementation to either determine the worst-case stack requirement
if the stated limits are never exceeded, or reject a program if a directive
asks it to validate the worst-case stack requirement and it is unable to do
so].

At present, the Standard does not require that a conforming implementation
be able to run any particular program, other than its One Program, without
blowing the stack.  I would suggest that the Standard would be much more of
a real standard if it defined a class of programs, called Selectively-
Conforming programs, which implementations would be allowed to reject
without being non-conforming (but which quality implementations should try
to support when practical), but which will run without UB on all conforming
implementations that do not reject them.

> How many such macros would you want to add to the language?  How much
> bigger would the standard document have to be to describe them all?

The amount of extra text required would be less than the amount of text the
Standard devotes to many things which are applicable in far fewer situations
than would be a definition of programs that can be guaranteed not to invoke
UB on any conforming implementation, and which would be applicable to 
programs accomplishing a much broader range of tasks than the rather
anemic "strictly-conforming".

[toc] | [prev] | [next] | [standalone]

#95246

supercat@casperkitty.com writes:
> On Monday, October 24, 2016 at 2:05:09 PM UTC-5, Keith Thompson wrote:
[...]
>> How many such macros would you want to add to the language?  How much
>> bigger would the standard document have to be to describe them all?
>
> The amount of extra text required would be less than the amount of text the
> Standard devotes to many things which are applicable in far fewer situations
> than would be a definition of programs that can be guaranteed not to invoke
> UB on any conforming implementation, and which would be applicable to 
> programs accomplishing a much broader range of tasks than the rather
> anemic "strictly-conforming".

Glad we cleared that up.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#95248

supercat@casperkitty.com writes:

> On Saturday, October 22, 2016 at 3:44:05 PM UTC-5, Tim Rentsch wrote:
>> If the "more well-defined" point of view were adopted, then
>> everyone would be forced to pay the price for that, whether
>> they want to or not.
>
> What price?
>
> There is no circumstance in which complying with a requirement that using
> memcpy with size zero must be an unconditional nop would require a compiler
> to generate more than one extra comparison in any defined case, and cases
> where even that would be required would be exceptionally rare and unlikely
> to occur outside of contrived scenarios.
>
> By contrast, situations in which the an operand (especially the source)
> might be null when the size is zero occur fairly often when implementing
> some APIs, and handling them in accordance with the present standard would
> require that programmers add comparisons in source code which will not be
> needed in the executable code, but which compilers may not be able to
> optimize out.

Obviously you understand that there are costs involved in the
first case (and also the second), since you have identified some
of them.

I'm sure this will come as a complete and utter shock and
surprise to you, but not everyone shares your engineering
judgments.  Apparently the people responsible for making the
decision here reached a different conclusion than you would about
what tradeoffs are the best choice in this case.  I haven't seen
any convincing arguments for second-guessing them on this issue.
Yours included.

[toc] | [prev] | [next] | [standalone]

#95251

On Monday, October 24, 2016 at 4:16:44 PM UTC-5, Tim Rentsch wrote:
> I'm sure this will come as a complete and utter shock and
> surprise to you, but not everyone shares your engineering
> judgments.  Apparently the people responsible for making the
> decision here reached a different conclusion than you would about
> what tradeoffs are the best choice in this case.  I haven't seen
> any convincing arguments for second-guessing them on this issue.
> Yours included.

The authors of the C89 weren't trying to make engineering judgments
about what behaviors should be supported by quality implementations
for commonplace machines.  In many cases it made sense to have some
features and guarantees supported by platforms where they would be
useful and cheap, but not supported on those platforms where they
would be expensive and not very useful, and I see no reason to believe
the authors of the Standard wanted to discourage that.

The question of which machines should support which features was left
as a matter of engineering judgment to the authors of individual
implementations; most features would either cost so little that there
would be little reason not to support them, or would cost too much to
justify having them supported by default.

What has changed over the years is that changes in optimization techniques
have caused the costs of some features and guarantees to increase somewhat.
In many cases, the cost would still be below the benefit that could be
received by code which exploits the feature, but removing support *from
code which would receive no benefit* would improve efficiency. Unfortunately
some compiler writers have no interest in evaluating the possible benefits
such behavioral guarantees produce when programmers are allowed to use them.

[toc] | [prev] | [next] | [standalone]

#95283

supercat@casperkitty.com writes:

> On Monday, October 24, 2016 at 4:16:44 PM UTC-5, Tim Rentsch wrote:
>> I'm sure this will come as a complete and utter shock and
>> surprise to you, but not everyone shares your engineering
>> judgments.  Apparently the people responsible for making the
>> decision here reached a different conclusion than you would about
>> what tradeoffs are the best choice in this case.  I haven't seen
>> any convincing arguments for second-guessing them on this issue.
>> Yours included.
>
> The authors of the C89 weren't trying to make engineering judgments
> about what behaviors should be supported by quality implementations
> for commonplace machines.  [...]

Perhaps not but those aren't the judgments I'm talking about.

[toc] | [prev] | [next] | [standalone]

#95153

On 10/22/2016 11:49 AM, Lőrinczy Zsigmond wrote:
> Thank you for your answer,
> I'm willing to believe this people are great guys,
> but even then, their product (the text of standard)
> is lacking:
> 
> "The behavior is undefined if either dest or src is a null pointer."

It's not actually worded that way. 7.1.4 says, with reference to the
entire C standard library, says "... an invalid value (such as ... a
null pointer, ...)".

7.24.1p2 says, with respect only to <string.h>, that "Where an argument
declared as size_t n specifies the length of the array for a function, n
can have the value zero on a call to that function. Unless explicitly
stated otherwise in the description of a particular function in this
subclause, pointer arguments on such a call shall still have valid
values, as described in 7.1.4."


> This sentence should be either removed or changer to:
> 
> "The behavior is undefined if either dest or src is a null pointer
> and length>0."

Your desired change would be achieved by changing "shall still" to "need
not" in 7.24.1.p2.

I want to emphasize that I would not object to making this change,
mainly because I'm having trouble imagining a platform where it would be
difficult to conform to such a requirement. This may be due to a failure
of my imagination. I find it equally difficult to imagine a situation
where it would be a significant burden for the calling routine to make
sure that the pointers aren't null before executing the call.

[toc] | [prev] | [next] | [standalone]

#95166

I just realized I left out a key word:

On 10/22/2016 10:31 AM, James Kuyper wrote:
...
> ... I believe that one thing that virtually
> every member of the committee shares ...

is

> ... extensive experience programming in
> C.

[toc] | [prev] | [next] | [standalone]

#95170

On 23/10/16 15:44, James R. Kuyper wrote:
> I just realized I left out a key word:
>
> On 10/22/2016 10:31 AM, James Kuyper wrote:
> ...
>> ... I believe that one thing that virtually
>> every member of the committee shares ...
>
> is
>
>> ... extensive experience programming in
>> C.
>

This sentence now verb!

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#95181 — Re: Verbing

On 23/10/2016 17:24, Richard Heathfield wrote:

> This sentence now verb!

Perhaps you meant "this sentence now verbs" :-p

http://www.gocomics.com/calvinandhobbes/1993/01/25

Regards.

[toc] | [prev] | [next] | [standalone]

#95163

supercat@casperkitty.com wrote:

> I regard that philosophy as broken.  I would suggest that part of what
> makes something a *quality* low-level language is that the source code
> should only need to include the edge-handling logic which actually needs
> to be included in the executable.

So you would expect to have the error elimination code removed from user
code and put into the library and compiler.

Isn't that a property of _high_-level languages?

Richard

[toc] | [prev] | [next] | [standalone]

#95165

On Sunday, October 23, 2016 at 2:26:43 PM UTC+1, Richard Bos wrote:
> supercat@casperkitty.com wrote:
> 
> > I regard that philosophy as broken.  I would suggest that part of what
> > makes something a *quality* low-level language is that the source code
> > should only need to include the edge-handling logic which actually needs
> > to be included in the executable.
> 
> So you would expect to have the error elimination code removed from user
> code and put into the library and compiler.
> 
> Isn't that a property of _high_-level languages?
> 
I think it depends on the operation.

It's the string of no sausages versus no string of sausages problem.
Eating them in either case is a no-op, but in the first case it
is clearly allowed, in the second case it may or may not be allowed.
It a high level-language, often the solution is that that latter
operation is forbidden, you must explicitly set up a list of 
sausages and say that its number of members is zero. In a low
level language, the distinction is often a bit unclear.

[toc] | [prev] | [next] | [standalone]

#95142

On Friday, October 21, 2016 at 12:47:17 PM UTC+2, Lorinczy Zsigmond wrote:
> Also let me note, that on my PowerPC computer the following program
> works without problem (AIX6.1, 32 and 64 bit, gcc-4.8.3 compiler),
> (I _would_ be angry if it didn't work)
> 
> /* memcpy_test.c */
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> 
> static int Test1 (void *to, const void *from, size_t len);
> 
> int main (void)
> {
>      char buff [64];
> 
>      Test1 (NULL, NULL, 0);
>      Test1 (buff, NULL, 0);
>      Test1 (buff, NULL, 64);
> 
>      return 0;
> }
> 
> static int Test1 (void *to, const void *from, size_t len)
> {
>      void *p = memcpy (to, from, len);
> 
>      printf ("(%p,%p,%d) returned %p\n",
>          to, from, (int)len, p);
> 
>      return p!=NULL;
> }
> 
> (0,0,0) returned 0
> (ffffffffffff390,0,0) returned ffffffffffff390
> (ffffffffffff390,0,64) returned ffffffffffff390
> 
> Note: the last one fails on linux, as address zero is not readable.
For me would be ok if one program would read memory out its memory the program has assigned (and seg fault for the memory wrote out its memory space) ... But in many PC I see even one read out its memory go to seg fault: So the last one that read in memory **has to seg fault** in every PC use windows and Linux if address 0 is not assigned to that prog (99.99 % of cases) 
 (

[toc] | [prev] | [next] | [standalone]

#95146

That might be very true, but not really relevant
when talking about the standard describing
function 'memcpy'

IMHO it could mention that reading from unreadable address,
or writing into unwriteable address is UB,
but that is true for every function dealing with pointers.

I think, important points would be these:

* if len==0, memcpy should do nothing
* if the from-area and to-area overlap, it is UB
* if from+len<from or to+len<to (address wrap-around), it is UB

[toc] | [prev] | [next] | [standalone]

#95154

Lőrinczy Zsigmond <nospam@for.me> writes:
> That might be very true, but not really relevant
> when talking about the standard describing
> function 'memcpy'

What might be very true?  Please quote some context from the article
you're replying to.

> IMHO it could mention that reading from unreadable address,
> or writing into unwriteable address is UB,
> but that is true for every function dealing with pointers.
>
> I think, important points would be these:
>
> * if len==0, memcpy should do nothing

That would have been a reasonable definition, but it's not what the
standard says.  Your opinion that it *should* do nothing in that
case is a perfectly valid one, but it's not one that everyone shares.

Personally, I have no particular problem with memcpy(NULL, NULL, 0)
having undefined behavior.  I've never written non-contrived code that
would be affected by it, and if I needed to I'd simply add an if
statement and move on.

> * if the from-area and to-area overlap, it is UB

Already specified.

> * if from+len<from or to+len<to (address wrap-around), it is UB

Already specified, though not in those terms.  The standard says nothing
about address arithmetic wrapping around; it simply makes certain
operations undefined behavior.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.lang.c

csiph-web