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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#94985

Off-topic: remember instruction MVCL of IBM System/370?
First, it checks for length==0,
then validated the address if the length is not zero.

That's how a programmer's mind should work.

(Actually, it takes two lengths: from-length and
to-length, plus a fill-character...
and it is a mere machine-instruction,
not a library function)

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

#95118

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.

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

#95128

On Friday, October 21, 2016 at 5:47:17 AM UTC-5, 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),

The question is not whether memcpy(0,0,0) will "usually" do nothing.  The
question is whether it could cause failure in cases like:

    // Produce a new heap object that concatenates the characters "ACME"
    // along with the contents of two memory ranges.  Pass 0,0 for unused
    // ranges.

    char *make_new_acme_thing(char *dat1, uint32_t len1, 
                              char *dat2, uint32_t len2)
    {
      char *ret = malloc(4+len1+len2);
      memcpy(ret, "ACME", 4);
      memcpy(ret+4, dat1, len1);
      memcpy(ret+4+len1, dat2, len2);
    }

    // Make a new object concatenating "ACME", the 8-digit hex
    // representation of num, and the supplied memory contents.  Pass
    // NULL,0 for the memory contents to produce an object containing
    // only "ACME" and the number.

    char *make_acme_hex8_thing(uint32_t num, char *dat, uint32_t len)
    {
      char temp[9];
      sprintf(temp,"%8X",num);
      if (dat)
        printf("First byte of dat is %02X\n", *dat);
      return make_new_acme_thing(temp, 8, dat, len);
    }

Modern compiler philsophy would suggest that a quality compiler should
eliminate the null-check for "dat" from make_acme_hex8_thing since
passing a null pointer to that function would cause Undefined Behavior
in the memcpy.

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.  The null check in make_acme_hex8_thing
needs to be included in the executable to meet requirements, while no
special size-zero check would need to be included in the executable code
of either function.

If one wants to argue that there should exist a high-level language which
uses the same syntax as C, I would agree that such a thing would be useful
for some purposes, but I would not regard it as being fundamentally
different from the language Dennis Ritchie invented and called C.  Further,
I would suggest that anyone designing such a language try to minimize the
number of cases where boundary logic would be needed in source text but not
the executable.  If a programmer has to write useless boundary-handling
logic, an optimizer will have to go through a lot of work just to get back
to the level of efficiency that would have been achieved if that logic never
needed to be written in the first place.

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

#95134

I do agree with you.

On another thought, I'd like to mention that in real life the compiler
and the C-runtime-library might be written by different people,
so the compiler shouldn't think that
'yay, memcpy will fail if ptr==NULL,
so it's okay to ignore whatever the programmer has written,
cos the program will abort anyways'

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

#95135

On Friday, October 21, 2016 at 11:30:59 AM UTC-5, Lőrinczy Zsigmond wrote:
> 'yay, memcpy will fail if ptr==NULL,
> so it's okay to ignore whatever the programmer has written,
> cos the program will abort anyways'

The rationale isn't that the program will abort anyway--the philosophy
is that programmers have no right to expect any behaviors which aren't
mandated by the Standard, and thus compiler writers should feel no
obligation to support them.

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

#95141

Oh, okay; problem is that the standard
(at least this part) seems to have been written
by lawyers, not mathematicians/programmers:
the main idea is deflecting responsibility,
instead of handling every cases.

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

#95150

On 10/22/2016 01:42 AM, Lőrinczy Zsigmond wrote:
> Oh, okay; problem is that the standard
> (at least this part) seems to have been written
> by lawyers, not mathematicians/programmers:
> the main idea is deflecting responsibility,
> instead of handling every cases.

The C committee that wrote the standard contains a wide variety of
people with different backgrounds, some of them are implementors of C,
others are users of C. However, I believe that one thing that virtually
every member of the committee shares extensive experience programming in
C. I also very much doubt that there's any significant amount of formal
legal training on the committee (I wouldn't be surprised if ISO retains
some lawyers that the committee could make use of, if necessary - but
not on the committee itself).
A large number of highly experience C programmers reached a different
conclusion than you did about the advisability of writing the standard
to required "handling every case". Their basic attitude seems to be that
"you shouldn't write the kind of code that would make this break, so an
implementation is not required to prevent such breakage". If you
disagree about the  "shouldn't" part, then obviously you'll find that
conclusion disturbing.

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

#95151

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."

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."

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

#95152

Lorinczy Zsigmond <nospam@for.me> writes:

> 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."
>
> 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."

That is a perfectly reasonable point of view to hold.  However,
not everyone agrees, even not counting people on the standards
committee.  It isn't possible to satisfy both groups of people
with one definition.  How do you propose to resolve that
inherent inconsistency?

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.

If the existing semantics remains in force, it's easy to get the
more well-defined semantics for those who want it (other
variations are also possible):

    #include <string.h>
    #undef memcpy
    static inline void *
    better_memcpy( void *d, const void *s, size_t n ){
        return  n > 0 ? memcpy( d, s, n ) : d;
    }
    #define memcpy better_memcpy

ISTM the current approach provides more flexibility.  How would
you respond to that?

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

#95156

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.

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

#95167

On 10/23/2016 01:47 AM, Lőrinczy Zsigmond wrote:
> How to resolve this? It is not possible,
> it cannot be resolved;
> the standard is out, ...

It's been out for a quarter-century now, but it's also subject to 
revision, and has in fact been revised twice as a whole, and at least 5 
other times that I can remember by "Technical Corrigenda". Major 
revisions occur about once a decade; discussions of the next standard by 
the committee might have already started. I suggested a simple change to 
7.24.1p2 that would address your issue. Since it basically reverses the 
meaning of the sentence being changed, such a change would be a hard 
sell, but not impossible.

...
> Also there is no point in changing the standard,
> or fix this in later versions,
> it would only increase the chaos.

Defining behavior that had previously been undefined generally causes no 
more chaos than would have been caused if it had been defined from the 
beginning, particularly if the newly defined behavior matches the 
current actual behavior on most implementations. Very few programs 
should have been written to rely upon such code, and if they did, they 
probably relied upon the same behavior that is now the defined behavior 
of that code.
It's changes in the other direction that can cause serious problems.

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

#95175

Well, world is full of old systems;
you can find WindowsXP's and AIX5.3's everywhere...
So from now on (or since c99), if you want to write programs
that run everywhere, you cannot expect memcpy to hande len==0
properly, even if it were to be fixed in a later version.

I guess next time I'll find out that according to the standard,
strnlen(NULL,0) or memcmp(p,q,0) is UB, too...

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

#95183

On 10/23/2016 11:45 AM, Lőrinczy Zsigmond wrote:
> Well, world is full of old systems;
> you can find WindowsXP's and AIX5.3's everywhere...
> So from now on (or since c99), if you want to write programs
> that run everywhere, you cannot expect memcpy to hande len==0
> properly, even if it were to be fixed in a later version.

I always target the latest approved version of the standard, if I can, 
and complain to vendors about the fact that they don't support it yet, 
rather than targeting a particular compiler and complaining about the 
fact that the obsolete version of the standard that it currently 
supports doesn't do what I want. I guess I'm funny that way - the other 
approach seems to be oddly popular. What anyone is supposed to do about 
the second kind of complaint isn't clear. Fixing the standard obviously 
won't solve the problem, since that's already been done.

> I guess next time I'll find out that according to the standard,
> strnlen(NULL,0) or memcmp(p,q,0) is UB, too...

memcmp() and strlen() are both declared in <string.h>, and are therefore 
covered by the same rules as memcpy().

There is no function named strnlen() in the C standard library 
(K.3.7.4.4). There is a function names strnlen_s() declared in 
<string.h>, but only if _ _STDC_WANT_LIB_EXT1_ _ is #defined with a 
value of 1 before <string.h> is first #included. This is a part of the 
optional bounds-checking interfact that's new in C2011, and described in 
Annex K. If you're required to write code that conforms to C99, you 
can't use strnlen_s(s, maxsize). "If s is a null pointer, then the 
strnlen_s function returns zero." (K.3.7.4.4p3). "At most the first 
maxsize characters of s shall be accessed by strnlen_s." (p4), so 
strnlen(s, 0) should safely return 0 even if s cannot be safely 
dereferenced.

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

#95225

On Sunday, October 23, 2016 at 10:46:04 AM UTC-5, Lőrinczy Zsigmond wrote:
> Well, world is full of old systems;
> you can find WindowsXP's and AIX5.3's everywhere...
> So from now on (or since c99), if you want to write programs
> that run everywhere, you cannot expect memcpy to hande len==0
> properly, even if it were to be fixed in a later version.

There exists some date prior to which no implementation targeting the x86
architecture would treat memcpy(any,any,0) as anything other than a NOP,
nor treat memcpy(same,same,any) as having any effects which would differ
from those of memmove.

If the Standard were to changed to mandate such behavior, the only problem
would be compilers written in the window between when someone got the
brilliant idea to "optimize" based on the fact that it's not a guaranteed
no-op and the time the compiler was upgraded to conform to the Standard.
Since such compiler versions are most likely buggy in other ways, making
memcpy(any,any,0) behave as no-op in all cases could easily be rolled in
with other fixes.

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

#95227

supercat@casperkitty.com writes:
> On Sunday, October 23, 2016 at 10:46:04 AM UTC-5, Lőrinczy Zsigmond wrote:
>> Well, world is full of old systems;
>> you can find WindowsXP's and AIX5.3's everywhere...
>> So from now on (or since c99), if you want to write programs
>> that run everywhere, you cannot expect memcpy to hande len==0
>> properly, even if it were to be fixed in a later version.
>
> There exists some date prior to which no implementation targeting the x86
> architecture would treat memcpy(any,any,0) as anything other than a NOP,
> nor treat memcpy(same,same,any) as having any effects which would differ
> from those of memmove.
>
> If the Standard were to changed to mandate such behavior, the only problem
> would be compilers written in the window between when someone got the
> brilliant idea to "optimize" based on the fact that it's not a guaranteed
> no-op and the time the compiler was upgraded to conform to the Standard.
> Since such compiler versions are most likely buggy in other ways, making
> memcpy(any,any,0) behave as no-op in all cases could easily be rolled in
> with other fixes.

You seem to be suggesting that there are implementations where
memcpy(maybe_NULL, maybe_NULL, 0) is not a no-op.  Have you actually
encountered such an implementation?  Of course such an implementation is
permitted, but does it actually exist?

-- 
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]

#95233

On Monday, October 24, 2016 at 10:38:42 AM UTC-5, Keith Thompson wrote:
> You seem to be suggesting that there are implementations where
> memcpy(maybe_NULL, maybe_NULL, 0) is not a no-op.  Have you actually
> encountered such an implementation?  Of course such an implementation is
> permitted, but does it actually exist?

I have not encountered such an implementation, but it's not at all hard
to imagine one that would take:

    // Calling contract requires that either extraDat be null and size
    // zero, or that extraDat identify a valid Widget object.

    void foo( ...  extraDat, extraSize)
    {
      ...
      if (extraDat)
        useWidgetHeader(extraDat);
      ...
      memcpy(buff, extraDat, extraSize);
      ...
    }

and omit the null-check on extraDat.  If no non-sanitizing implementation
would ever treat memcpy(any,any,0) as anything other than a no-op, then a
requirement that implementations must treat it as a no-op would cost
nothing beyond changing sanitizing builds to not squawk at programs which
work would work on any non-sanitizing implementation.  If, however, no
existing implementations would do so but future compiler writers would
implement "optimizations" like the above if allowed to do so, prohibiting
such behavior in advance would allow those compiler writers to direct their
efforts in more useful fashion.

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

#95198

Lőrinczy 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.

When you post a followup, please retain enough quoted context
from the parent article, including attribution lines, so that your
followup makes sense.  I see you're using Thunderbird; I'm reasonably
sure it will do this for you.

What exactly needs to be "resolved"?  The standard is clear that
the behavior of memcpy(NULL, NULL, 0) is undefined.  If you want
to assume that it's a harmless no-op, you're free to do so; your
implementation might support that assumption, but the standard
doesn't.  If you're writing an implementation, you can make it
behave as a harmless no-op; that's entirely consistent with what
the standard requires.  If you want a future edition of the standard
to define the behavior, you can certainly advocate such a change.

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.

-- 
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]

#95202

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.

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

#95206

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 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.

Yes, the behavior of malloc(0) is implementation-defined.  You need to
be aware of that and allow for it.

-- 
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]

#95219

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)

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

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

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

csiph-web