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

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

Query abt union

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

Contents

  Query abt union "sumit.sharma" <nospam@nospam.com> - 2011-06-23 20:07 +0000
    Re: Query abt union Ben Pfaff <blp@cs.stanford.edu> - 2011-06-23 13:18 -0700
    Re: Query abt union Shao Miller <sha0.miller@gmail.com> - 2011-06-23 17:20 -0500
      Re: Query abt union James Waldby <not@valid.invalid> - 2011-06-24 17:34 +0000
        Re: Query abt union Shao Miller <sha0.miller@gmail.com> - 2011-06-24 14:42 -0400
          Re: Query abt union James Waldby <not@valid.invalid> - 2011-06-24 21:13 +0000
            Re: Query abt union Shao Miller <sha0.miller@gmail.com> - 2011-06-26 14:08 -0500
              Re: Query abt union James Waldby <not@valid.invalid> - 2011-06-27 05:13 +0000
    Re: Query abt union John Gordon <gordon@panix.com> - 2011-06-23 22:27 +0000
    Re: Query abt union Lew Pitcher <lpitcher@teksavvy.com> - 2011-06-23 18:47 -0400
      Re: Query abt union Shao Miller <sha0.miller@gmail.com> - 2011-06-23 17:54 -0500
        Re: Query abt union Keith Thompson <kst-u@mib.org> - 2011-06-23 17:19 -0700
          Re: Query abt union Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-23 22:12 -0600
            Re: Query abt union Keith Thompson <kst-u@mib.org> - 2011-06-23 22:32 -0700
              Re: Query abt union Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-24 08:51 -0600
                Re: Query abt union Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-06-24 16:30 +0100
            Re: Query abt union pete <pfiland@mindspring.com> - 2011-06-24 12:46 -0400
              Re: Query abt union Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-24 16:18 -0600
          Re: Query abt union pozz <pozzugno@gmail.com> - 2011-06-24 23:14 +0200
            Re: Query abt union John Gordon <gordon@panix.com> - 2011-06-24 21:37 +0000
              Re: Query abt union Shao Miller <sha0.miller@gmail.com> - 2011-06-26 14:28 -0500
            Re: Query abt union Keith Thompson <kst-u@mib.org> - 2011-06-24 14:56 -0700
              Re: Query abt union Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-06-24 22:10 +0000
                Re: Query abt union Keith Thompson <kst-u@mib.org> - 2011-06-24 15:41 -0700
            Re: Query abt union pete <pfiland@mindspring.com> - 2011-06-25 10:33 -0400
              Re: Query abt union pete <pfiland@mindspring.com> - 2011-06-25 15:30 -0400
            Re: Query abt union Shao Miller <sha0.miller@gmail.com> - 2011-06-26 14:12 -0500
      Re: Query abt union Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-23 17:13 -0600

Page 2 of 2 — ← Prev page 1 [2]

#6981

On 6/24/2011 4:37 PM, John Gordon wrote:
> In<iu2un1$ne7$1@nnrp.ngi.it>  pozz<pozzugno@gmail.com>  writes:
>
>>     char mystring[10];
>>     void mystrcpy(const char *arg) {
>>       strncpy(mystring, arg, sizeof(mystring) - 1);
>>       mystring[sizeof(mystring) - 1] = '\0';
>>     }
>
> A quibble with this particular implementation:  Your wrapper function uses
> sizeof to get the size of the destination buffer, which a general-purpose
> function wouldn't be able to do.
>

If it was a general-purpose function, it also wouldn't know where to 
copy it to without another parameter.  So maybe:

   #define MAX_STRING_SIZE (10)

   enum cv {
       cv_max_string_size = MAX_STRING_SIZE,
       cv_zero = 0
     }

   typedef char a_my_string_buf[cv_max_string_size];

   void my_strcpy(a_my_string_buf * const dest, const char * const src) {
       strncpy(*dest, src, sizeof *dest - 1);
       (*dest)[sizeof *dest - 1] = 0;
       return;
     }

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

#6897

pozz <pozzugno@gmail.com> writes:
> Il 24/06/2011 02:19, Keith Thompson ha scritto:
>> General rule: Don't use strncpy unless you really understand what it
>> does.  (And if you understand what it does, you probably won't want to
>> use it.)
>
> Sorry, but I'm not able to follow your discussion. Why should I avoid 
> strncpy()?
>
> I have a string buffer defined with a fixed dimension:
>    char mystring[10];
>
> Now I have to copy an unknown string, maybe passed in as an argument 
> function, to mystring array. If I use strcpy(), I could write memory 
> after mystring[].
>
> So I think strncpy() is good to avoid this bad situations:
>
>    char mystring[10];
>    void mystrcpy(const char *arg) {
>      strncpy(mystring, arg, sizeof(mystring) - 1);
>      mystring[sizeof(mystring) - 1] = '\0';
>    }
>
> What is wrong with this?

strncat() is a safer version of strcat(); it takes an extra argument,
n, that specifies the maximum number of characters to copy.
It guarantees that, unless you go past the bounds of the source
or the destination, the destination will contain a valid (i.e.,
null-terminated) string.

strncpy(), in spite of the misleading name, is *not* a safer version
of strcpy().  strncpy() can easily leave the destination array in
a state where it doesn't contain a valid string.  If n is much
larger than the size of the source, it will pad the destination
with multiple null characters, which is usually not useful.

A function that is to strcpy() as strncat() is to strcat() would
be useful, and strncpy() would have been a good name for it.
But there is no such function in the standard library (thought it's
easy enough to roll your own), and the name strncpy() is already
taken for this bizarre thing.

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

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

#6901

Keith Thompson wrote:
> A function that is to strcpy() as strncat() is to strcat() would be
> useful, and strncpy() would have been a good name for it. But there is
> no such function in the standard library (thought it's easy enough to
> roll your own), and the name strncpy() is already taken for this bizarre
> thing.

I think the function you're looking for is strlcpy(), present in most 
modern C distributions but easy enough to write oneself should it be 
absent. It helpfully returns the length of the source string, so you can 
use constructions like

if(strlcpy(buf, src, sizeof buf) >= sizeof buf) {
  /* truncation happened */
}

//EPR

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

#6905

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> Keith Thompson wrote:
>> A function that is to strcpy() as strncat() is to strcat() would be
>> useful, and strncpy() would have been a good name for it. But there is
>> no such function in the standard library (thought it's easy enough to
>> roll your own), and the name strncpy() is already taken for this bizarre
>> thing.
>
> I think the function you're looking for is strlcpy(), present in most 
> modern C distributions but easy enough to write oneself should it be 
> absent. It helpfully returns the length of the source string, so you can 
> use constructions like
>
> if(strlcpy(buf, src, sizeof buf) >= sizeof buf) {
>   /* truncation happened */
> }

It's not necessarily what I'm looking for.  What I really had in mind
for what strncpy() *should* have been is a function that's to strcpy()
exactly as strncat() is to strcat().

(Note that strlcpy() may well be *better* than any of strcpy(),
strncpy(), or what-strncpy-should-have-been().)

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

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

#6927

pozz wrote:
 
> So I think strncpy() is good to avoid this bad situations:
> 
>    char mystring[10];
>    void mystrcpy(const char *arg) {
>      strncpy(mystring, arg, sizeof(mystring) - 1);
>      mystring[sizeof(mystring) - 1] = '\0';
>    }
> 
> What is wrong with this?

Why wouldn't you use memcpy instead of strncpy
in the above code?

memcpy is the simpler of the two functions.

The extra features which distiguish strncpy from memcpy 
are only useful in the above code
if you really want mystring 
to be padded out to the end with null bytes.

-- 
pete

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

#6936

pete wrote:
> 
> pozz wrote:
> 
> > So I think strncpy() is good to avoid this bad situations:
> >
> >    char mystring[10];
> >    void mystrcpy(const char *arg) {
> >      strncpy(mystring, arg, sizeof(mystring) - 1);
> >      mystring[sizeof(mystring) - 1] = '\0';
> >    }
> >
> > What is wrong with this?
> 
> Why wouldn't you use memcpy instead of strncpy
> in the above code?
> 
> memcpy is the simpler of the two functions.
> 
> The extra features which distiguish strncpy from memcpy
> are only useful in the above code
> if you really want mystring
> to be padded out to the end with null bytes.

I take that back.
It would be more complicated with memcpy.
You would have to provide code to prevent memcpy
from reading beyond a short string.

-- 
pete

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

#6980

On 6/24/2011 4:14 PM, pozz wrote:
>
> char mystring[10];
> void mystrcpy(const char *arg) {
>   strncpy(mystring, arg, sizeof(mystring) - 1);
>   mystring[sizeof(mystring) - 1] = '\0';
> }
>
> What is wrong with this?

Here's a note which is unrelated to "right" or "wrong" :)

The parentheses around 'mystring' are redundant.

   char mystring[10];
   void mystrcpy(const char * arg) {
       strncpy(mystring, arg, sizeof mystring - 1);
       mystring[sizeof mystring - 1] = '\0';
     }

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

#6769

Lew Pitcher <lpitcher@teksavvy.com> writes:

> On June 23, 2011 16:07, in comp.lang.c, nospam@nospam.com wrote:
>
> [snip]
>> union MyUnion
>>     {
>>     char name [100];
>>     double dblval;
>>     int    intVal;
>>     };
>>
> [snip]
>>> MyUnion ux;
>> 
>> strncpy(ux.name, "C Language", strlen("C Langage"));    /* name is set */
>
> As an aside, the above illustrates a common problem found when programmers
> overuse string literals.  Here, the strncpy() will result in ux.name being
> set to the string array "C Languag", dropping the final "e"
>
> Do you see why? Hint: it has to do with the string literals.

Ah, I didn't see that one (requires very careful reading!).  I was about
to post another, worse bug in the same line:  it guarantees no trailing
null at the end of the string (we just had a brief discussion of
strncpy()'s problem in this regard!).  Better would be

   strncpy(ux.name, "C Language", sizeof(ux.name));
   ux.name[sizeof(ux.name)-1] = '\0';

Though this is, of course, inefficient.

Somebody else suggested using strcpy(); since the string being copied is
a literal a good code review will would then establish no buffer
overrun.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web