Consideration on pointer declarations

Discussion in 'C Programming' started by Starman, Mar 5, 2009.

  1. Starman

    Starman Guest

    This is something I've pondered on for some years. The pointer symbol
    * is tied to the variable, not to the type. So in all the code I've
    seen so far I found:

    char *pc;

    however I would (and I tend to) write:

    char* pc;

    I know the second is not syntactically correct because
    char *pc1, *pc2; // works
    char* pc1, pc2; // does not work.

    But I find the second syntax much more natural and easier to read
    through.

    This syntax has always given me problems in particular when
    deciphering other people's code, especially when it comes to pointers
    to pointers like often found in function parameters.
    Since the * symbol is also used for dereferencing a pointer, I often
    get confused and I have to stop and think the code through (and lose
    quite a bit of time).

    I was wondering if others think it the same way.
     
    Starman, Mar 5, 2009
    #1
    1. Advertising

  2. Starman

    Shiyou Wang Guest

    Starman wrote:

    > This is something I've pondered on for some years. The pointer symbol
    > * is tied to the variable, not to the type. So in all the code I've
    > seen so far I found:
    >
    > char *pc;
    >
    > however I would (and I tend to) write:
    >
    > char* pc;
    >
    > I know the second is not syntactically correct because
    > char *pc1, *pc2; // works
    > char* pc1, pc2; // does not work.
    >
    > But I find the second syntax much more natural and easier to read
    > through.
    >
    > This syntax has always given me problems in particular when
    > deciphering other people's code, especially when it comes to pointers
    > to pointers like often found in function parameters.
    > Since the * symbol is also used for dereferencing a pointer, I often
    > get confused and I have to stop and think the code through (and lose
    > quite a bit of time).
    >
    > I was wondering if others think it the same way.


    I had the same feeling at the begining, but now I become used to this
    convention. And I agree it would be more natural to tie the * with type.
     
    Shiyou Wang, Mar 5, 2009
    #2
    1. Advertising

  3. Starman <> writes:

    > This is something I've pondered on for some years. The pointer symbol
    > * is tied to the variable, not to the type. So in all the code I've
    > seen so far I found:
    >
    > char *pc;


    I would say this the more common form (some people consider a third:
    'char * pc;' by lets forget about that, yes?).

    > however I would (and I tend to) write:
    >
    > char* pc;
    >
    > I know the second is not syntactically correct because


    It is perfectly correct syntax. What you probably mean is that the
    layout does not mirror the syntax, where the * is part of what is
    called a declarator (the *pc bit).

    > char *pc1, *pc2; // works
    > char* pc1, pc2; // does not work.


    Well, it works, it just does not do what was probably intended. Both
    forms can be confusing for some people so you will see advice
    suggesting that one declare only one variable per declaration. The
    trouble with this is that you will have to read and understand code
    that does not do this. You'll have to get comfortable with it.

    > But I find the second syntax much more natural and easier to read
    > through.
    >
    > This syntax has always given me problems in particular when
    > deciphering other people's code, especially when it comes to pointers
    > to pointers like often found in function parameters.
    > Since the * symbol is also used for dereferencing a pointer, I often
    > get confused and I have to stop and think the code through (and lose
    > quite a bit of time).
    >
    > I was wondering if others think it the same way.


    I don't know. I feel as if it made sense from the start, but it was
    too long ago for me to be really sure.

    --
    Ben.
     
    Ben Bacarisse, Mar 5, 2009
    #3
  4. Starman

    Eric Sosman Guest

    Starman wrote:
    > This is something I've pondered on for some years. The pointer symbol
    > * is tied to the variable, not to the type. So in all the code I've
    > seen so far I found:
    >
    > char *pc;
    >
    > however I would (and I tend to) write:
    >
    > char* pc;
    >
    > I know the second is not syntactically correct because
    > char *pc1, *pc2; // works
    > char* pc1, pc2; // does not work.
    >
    > But I find the second syntax much more natural and easier to read
    > through.
    >
    > This syntax has always given me problems in particular when
    > deciphering other people's code, especially when it comes to pointers
    > to pointers like often found in function parameters.
    > Since the * symbol is also used for dereferencing a pointer, I often
    > get confused and I have to stop and think the code through (and lose
    > quite a bit of time).


    Maybe it will make more sense if you consider pointer
    variable declaration not as an isolated phenomenon, but as
    part of the larger scheme of the way C declares things. For
    example, how would you suggest writing

    double (*fptr)(double, double);

    .... in a "pointerness belongs with the type, not with the
    name" style?

    --
    Eric Sosman
    lid
     
    Eric Sosman, Mar 5, 2009
    #4
  5. Starman

    John Bode Guest

    On Thu, 05 Mar 2009 02:16:23 -0800, Starman wrote:

    > This is something I've pondered on for some years. The pointer symbol *
    > is tied to the variable, not to the type. So in all the code I've seen
    > so far I found:
    >
    > char *pc;
    >
    > however I would (and I tend to) write:
    >
    > char* pc;
    >
    > I know the second is not syntactically correct because char *pc1, *pc2;
    > // works
    > char* pc1, pc2; // does not work.
    >
    > But I find the second syntax much more natural and easier to read
    > through.
    >
    > This syntax has always given me problems in particular when deciphering
    > other people's code, especially when it comes to pointers to pointers
    > like often found in function parameters. Since the * symbol is also used
    > for dereferencing a pointer, I often get confused and I have to stop and
    > think the code through (and lose quite a bit of time).
    >
    > I was wondering if others think it the same way.


    Once I really understood what "declaration mimics use" meant with respect
    to C declarators, the pointer declaration syntax made much more sense.

    If you have a pointer to a char, you access the char value by using the
    dereference operator, like so:

    c = *pc;

    Thus, the type of the *expression* "*pc" is char, so the declaration is
    typically written as

    char *pc;

    Even though the type of pc is "pointer to char", the "pointerness" is
    tied to the declarator, not the type specifier.

    Similarly, if you have an array of pointers to int, you would access a
    specific int value by subscripting the array and dereferencing the
    specific entry:

    i = *api[k];

    Thus, the type of the expression "*api[k]" is int, so the declaration is
    written as

    int *api[N];

    Again, while api has type "N-element array of pointer to int", the
    "pointerness" and "arrayness" are tied to the declarator, not the type
    specifier.

    Think of it this way: you have no problem associating array subscripts
    with the declarator, do you (such as "char foo[N];")? But the same issue
    applies; the type of foo is "N-element array of char", but we don't
    declare it as

    char[N] foo;

    because again, declaration mimics use.
     
    John Bode, Mar 5, 2009
    #5
  6. Starman

    Bartc Guest

    "Eric Sosman" <> wrote in message
    news:gooiua$80c$...
    > Starman wrote:



    >> I know the second is not syntactically correct because
    >> char *pc1, *pc2; // works
    >> char* pc1, pc2; // does not work.
    >>
    >> But I find the second syntax much more natural and easier to read
    >> through.
    >>
    >> This syntax has always given me problems in particular when
    >> deciphering other people's code, especially when it comes to pointers
    >> to pointers like often found in function parameters.
    >> Since the * symbol is also used for dereferencing a pointer, I often
    >> get confused and I have to stop and think the code through (and lose
    >> quite a bit of time).

    >
    > Maybe it will make more sense if you consider pointer
    > variable declaration not as an isolated phenomenon, but as
    > part of the larger scheme of the way C declares things. For
    > example, how would you suggest writing
    >
    > double (*fptr)(double, double);
    >
    > ... in a "pointerness belongs with the type, not with the
    > name" style?


    In a different language that might look like:

    ref function(double,double)double [pointer to function taking
    (double,double) returning double]

    And you can declare six of the things with:

    ref function(double,double)double a,b,c,d,e,f

    C's unique type declaration syntax doesn't really help in separating things
    out (the type, and the name being declared, are all mixed together).

    (BTW it's taken me nearly half an hour to create this post, mostly scouring
    the web for an executable version of cdecl that works on my machine, or that
    didn't say 'syntax error' to nearly everything thrown at it. In the end I
    had to fire up another machine with a known working cdecl, just to
    understand your example. There must be something wrong if an utility is
    needed just to untangle type declarations! And it's not just me otherwise
    cdecl wouldn't exist.)

    --
    Bartc
     
    Bartc, Mar 5, 2009
    #6
  7. Starman

    Starman Guest

    On Mar 5, 7:10 am, Ben Bacarisse <> wrote:
    > > char *pc1, *pc2; // works
    > > char* pc1, pc2; // does not work.

    >
    > Well, it works, it just does not do what was probably intended.


    yes of course this is what I meant, it does not work in the sense
    that I would have expected to declare 2 pointers when instead I
    declare
    1 pointer-to-char and 1 char.
     
    Starman, Mar 5, 2009
    #7
  8. Starman

    Starman Guest

    Yes, this is a cool way of looking at it,
    thanks John

    On Mar 5, 2:19 pm, John Bode <> wrote:
    > ...
    > If you have a pointer to a char, you access the char value by using the
    > dereference operator, like so:
    >
    > c = *pc;
    >
    > Thus, the type of the *expression* "*pc" is char, so the declaration is
    > typically written as
    >
    > char *pc;
    >
     
    Starman, Mar 5, 2009
    #8
  9. Starman

    Bartc Guest

    "Starman" <> wrote in message
    news:...
    > On Mar 5, 7:10 am, Ben Bacarisse <> wrote:
    >> > char *pc1, *pc2; // works
    >> > char* pc1, pc2; // does not work.

    >>
    >> Well, it works, it just does not do what was probably intended.

    >
    > yes of course this is what I meant, it does not work in the sense
    > that I would have expected to declare 2 pointers when instead I
    > declare
    > 1 pointer-to-char and 1 char.


    White space has no significance in C so that char* s is the same as char *s.
    But char* does look like the * is part of the char type. And is even more
    confusing because char* can sometimes represent a complete type, as in
    (char*)p.

    Using typedefs however can help out:

    typedef char *string;

    string pc1,pc2; /* Both char * */

    --
    Bartc
     
    Bartc, Mar 5, 2009
    #9
  10. On Mar 5, 8:37 am, "Bartc" <> wrote:
    > "Eric Sosman" <> wrote in message
    >
    > news:gooiua$80c$...
    >
    >
    >
    > > Starman wrote:
    > >> I know the second is not syntactically correct because
    > >> char *pc1, *pc2; // works
    > >> char* pc1, pc2; // does not work.

    >
    > >> But I find the second syntax much more natural and easier to read
    > >> through.

    >
    > >> This syntax has always given me problems in particular when
    > >> deciphering other people's code, especially when it comes to pointers
    > >> to pointers like often found in function parameters.
    > >> Since the * symbol is also used for dereferencing a pointer, I often
    > >> get confused and I have to stop and think the code through (and lose
    > >> quite a bit of time).

    >
    > >     Maybe it will make more sense if you consider pointer
    > > variable declaration not as an isolated phenomenon, but as
    > > part of the larger scheme of the way C declares things.  For
    > > example, how would you suggest writing

    >
    > > double (*fptr)(double, double);

    >
    > > ... in a "pointerness belongs with the type, not with the
    > > name" style?

    >
    > In a different language that might look like:
    >
    > ref function(double,double)double  [pointer to function taking
    > (double,double) returning double]
    >
    > And you can declare six of the things with:
    >
    > ref function(double,double)double a,b,c,d,e,f
    >
    > C's unique type declaration syntax doesn't really help in separating things
    > out (the type, and the name being declared, are all mixed together).
    >
    > (BTW it's taken me nearly half an hour to create this post, mostly scouring
    > the web for an executable version of cdecl that works on my machine, or that
    > didn't say 'syntax error' to nearly everything thrown at it. In the end I
    > had to fire up another machine with a known working cdecl, just to
    > understand your example. There must be something wrong if an utility is
    > needed just to untangle type declarations! And it's not just me otherwise
    > cdecl wouldn't exist.)
    >
    > --
    > Bartc


    You should (re-)read /Deep C Secrets/, aka the Coelocanth
    (sp?) book. It's got a whole chapter on this and a
    detailed explanation of the cdecl program.

    It also has great stuff on pointer/array (un)equivalence,
    and a story about a NASA failure due to (X=Y) instead of
    (X=normalize(Y)). Overcompensating Feedback Loop Bug.

    lxt
     
    luser-ex-troll, Mar 5, 2009
    #10
  11. (Richard Harter) writes:

    > On Thu, 05 Mar 2009 12:10:18 +0000, Ben Bacarisse
    > <> wrote:
    >
    >>Starman <> writes:
    >>
    >>> This is something I've pondered on for some years. The pointer symbol
    >>> * is tied to the variable, not to the type. So in all the code I've
    >>> seen so far I found:
    >>>
    >>> char *pc;

    >>
    >>I would say this the more common form (some people consider a third:
    >>'char * pc;' by lets forget about that, yes?).
    >>

    >
    > No, let's not. My preferred style is to line things up
    > vertically, one declaration per line, each line commented with a
    > description of the variable. (Quite often I'm not that fussy in
    > practice.) Here is an example (horizontal space trimmed for
    > posting).
    >
    > DELIVERY {
    > AGENT_R agent_r; /* Agent receiving delivery */
    > PORT_NO port; /* Port receiving delivery */
    > size_t seqno; /* Expected inport serial number */
    > INPORT * inport; /* Pointer to agent inport struct */
    > };
    >
    > This may seem anal rententive, but I have found that it is very
    > good practice, both for writing code and for reading it later.
    > Thus, your coding experience will be happier if every variable
    > has a clear, well defined meaning. Putting one declaration per
    > statement has the happy side effect of never missing one of those
    > asterisks.


    Yes, I often do this as well but I am not fond of the lone *. I still
    glue it to the name when lining things up. Maybe this is because I
    seem to have a lot of function pointers in structures and it seems to
    look clearer with all those brackets (I think I'd use typedefs now if
    I re-wrote it).

    In the end you probably have to know what all the syntax means because
    you are likely to come across a lot of the possible variations. So,
    yes, you are right. Let's not forget about any of them!

    --
    Ben.
     
    Ben Bacarisse, Mar 5, 2009
    #11
  12. "Bartc" <> writes:
    [...]
    > White space has no significance in C so that char* s is the same as
    > char *s. But char* does look like the * is part of the char type. And
    > is even more confusing because char* can sometimes represent a
    > complete type, as in (char*)p.
    >
    > Using typedefs however can help out:
    >
    > typedef char *string;
    >
    > string pc1,pc2; /* Both char * */


    Hiding a type's "pointerness" behind a typedef is generally a bad
    idea, unless it's intended to be opaque (i.e., code that uses the type
    doesn't need to know that it's a pointer). Furthermore, a string is
    not a char*; a string is a contiguous sequence of characters. A char*
    can point to a string; it can't be a string.

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Mar 5, 2009
    #12
  13. Starman

    Bartc Guest

    "Eric Sosman" <> wrote in message
    news:1236268168.592879@news1nwk...
    > Bartc wrote:
    >>
    >> "Eric Sosman" <> wrote in message
    >>>
    >>> Maybe it will make more sense if you consider pointer
    >>> variable declaration not as an isolated phenomenon, but as
    >>> part of the larger scheme of the way C declares things. For
    >>> example, how would you suggest writing
    >>>
    >>> double (*fptr)(double, double);
    >>>
    >>> ... in a "pointerness belongs with the type, not with the
    >>> name" style?

    >>
    >> In a different language that might look like:
    >>
    >> ref function(double,double)double [pointer to function taking
    >> (double,double) returning double]


    > Language bloat is also an issue; note
    > that your example introduces two brand-new keywords.


    Two extra keywords might (or would have been) worth it, for intuitive type
    declarations (my example originated from Algol68 where it looks more like
    ref proc(real,real)real)

    >
    >> C's unique type declaration syntax doesn't really help in separating
    >> things out (the type, and the name being declared, are all mixed
    >> together).

    >
    > I don't think I understand your objection. What's wrong with
    > mixing things together?


    Er, nearly everything? :)

    It causes the OP's problem; it makes typespecs necessarily convoluted
    instead of linear; where a typespec needs to exist without a name (as in a
    cast), then it changes appearance (and is even more difficult to work out);
    and playing around with macros for declaration syntax is harder simply
    because types and names are not side-by-side.

    > For that matter, since the name-part is
    > "atomic" and must exist on its own somewhere, in what sense is it
    > "mixed?"


    I mean that the name can be in the middle of the type declaration.

    --
    Bartc
     
    Bartc, Mar 5, 2009
    #13
  14. Starman

    qarnos Guest

    On Mar 5, 9:16 pm, Starman <> wrote:

    > I was wondering if others think it the same way.


    I guess I'll take this opportunity to expose my weird coding style
    when it comes to declarations, particularly wrt pointers.

    I always have my specifiers and declarators spaced out with tabs so
    the declarations read like a table. I always have the '*' associated
    with the type, since that seems more natural to me and easier to read.

    I never have multiple declarators in a declaration, so there is no
    confusion over the intention of the declaration. This also makes it
    easy to comment the code (especially for doc generators such as
    doxygen), with the comments also aligned in tabular form.

    Here's an example of my style (usenet TAB gods willing):

    void foobar(void)
    {
    int * int_ptr; /*!< pointer to int */
    char * char_ptr; /*!< pointer to char */
    struct foo * struct_ptr; /*!< pointer to foo */
    }

    Obviously, in the real world I make the comments a bit more
    informative!

    You might think this style is weird (and you're probably right), but I
    find the table layout makes it much easier to lookup an identifier and
    find its type/description.
     
    qarnos, Mar 6, 2009
    #14
  15. Starman

    JosephKK Guest

    On Thu, 5 Mar 2009 07:04:54 -0800 (PST), Starman <>
    wrote:

    >On Mar 5, 7:10 am, Ben Bacarisse <> wrote:
    >> > char *pc1, *pc2; // works
    >> > char* pc1, pc2; // does not work.

    >>
    >> Well, it works, it just does not do what was probably intended.

    >
    >yes of course this is what I meant, it does not work in the sense
    >that I would have expected to declare 2 pointers when instead I
    >declare
    >1 pointer-to-char and 1 char.


    Somewhere in K&R and some other places they go to great lengths to
    explain how tightly various type modifier symbols like "*", ".", "->",
    and "&" bind to either the left or right but some of the logic keeps
    escaping me.
     
    JosephKK, Mar 11, 2009
    #15
  16. "JosephKK"<> writes:

    > On Thu, 5 Mar 2009 07:04:54 -0800 (PST), Starman <>
    > wrote:
    >
    >>On Mar 5, 7:10 am, Ben Bacarisse <> wrote:
    >>> > char *pc1, *pc2; // works
    >>> > char* pc1, pc2; // does not work.
    >>>
    >>> Well, it works, it just does not do what was probably intended.

    >>
    >>yes of course this is what I meant, it does not work in the sense
    >>that I would have expected to declare 2 pointers when instead I
    >>declare
    >>1 pointer-to-char and 1 char.

    >
    > Somewhere in K&R and some other places they go to great lengths to
    > explain how tightly various type modifier symbols like "*", ".", "->",
    > and "&" bind to either the left or right but some of the logic keeps
    > escaping me.


    Of those only * occurs in types. An operator table (K&R has one)
    explains how *, . etc bind in expressions.

    In types you have *, [] and (). All you need to remember is that
    (just as in expressions) the postfix ones [] and () bind more tightly
    than *. Some confusion comes from the fact that ()s are then use to
    alter the meaning -- i.e. there are two sorts of (). One means
    "function taking ..." and the other is syntactic.

    The upshot of that is that a declaration is read from the name
    outwards, always going right if you can (because there is a '[' or
    '(') and going left when you reach the end of the declarator (not the
    declaration) or a closing syntactic ')'.

    --
    Ben.
     
    Ben Bacarisse, Mar 11, 2009
    #16
  17. Starman

    JosephKK Guest

    On Wed, 11 Mar 2009 13:34:31 +0000, Ben Bacarisse
    <> wrote:

    >"JosephKK"<> writes:
    >
    >> On Thu, 5 Mar 2009 07:04:54 -0800 (PST), Starman <>
    >> wrote:
    >>
    >>>On Mar 5, 7:10 am, Ben Bacarisse <> wrote:
    >>>> > char *pc1, *pc2; // works
    >>>> > char* pc1, pc2; // does not work.
    >>>>
    >>>> Well, it works, it just does not do what was probably intended.
    >>>
    >>>yes of course this is what I meant, it does not work in the sense
    >>>that I would have expected to declare 2 pointers when instead I
    >>>declare
    >>>1 pointer-to-char and 1 char.

    >>
    >> Somewhere in K&R and some other places they go to great lengths to
    >> explain how tightly various type modifier symbols like "*", ".", "->",
    >> and "&" bind to either the left or right but some of the logic keeps
    >> escaping me.

    >
    >Of those only * occurs in types. An operator table (K&R has one)
    >explains how *, . etc bind in expressions.
    >
    >In types you have *, [] and (). All you need to remember is that
    >(just as in expressions) the postfix ones [] and () bind more tightly
    >than *. Some confusion comes from the fact that ()s are then use to
    >alter the meaning -- i.e. there are two sorts of (). One means
    >"function taking ..." and the other is syntactic.
    >
    >The upshot of that is that a declaration is read from the name
    >outwards, always going right if you can (because there is a '[' or
    >'(') and going left when you reach the end of the declarator (not the
    >declaration) or a closing syntactic ')'.


    Yes that is so. I still can get confused with typedefs of structs,
    expecially complex ones with embedded typedef'd unions. Any helpful
    words of wisdom there?
     
    JosephKK, Mar 12, 2009
    #17
  18. Starman

    Guest

    On 12 Mar, 03:46, "JosephKK"<> wrote:

    <snip>

    > [...] I still can get confused with typedefs of structs,
    > expecially complex ones with embedded typedef'd unions.  Any helpful
    > words of wisdom there.


    Same answer to any programming problem (or indeed any other sort
    of problem) in which complexity threatens to overwhelm you. Modularise
    (or divide and conquer).

    Hmm. Except I re-rwad your post. You say *typedefed unions*
    confuse you. I use typedefs to reduce confusion.

    Initially I thought you were confused by

    typedef struct
    {
    char name [1024];
    int serial_number;
    int version;
    int drive_type;
    union drive /* syntax of union not-checked */
    {
    Sublight slow;
    HyperDrive fast;
    };
    } Starship;

    and I was going to say lift the union out.

    typedef union
    {
    Sublight slow;
    HyperDrive fast;
    } StarshipDrive;

    typedef struct
    {
    char name [1024];
    int serial_number;
    int version;
    int drive_type;
    StarshipDrive drive;
    } Starship;

    If I've misunderstood gould you give an example of what confuses
    you?
     
    , Mar 12, 2009
    #18
  19. Starman

    JosephKK Guest

    On Thu, 12 Mar 2009 03:17:54 -0700 (PDT),
    wrote:

    >On 12 Mar, 03:46, "JosephKK"<> wrote:
    >
    ><snip>
    >
    >> [...] I still can get confused with typedefs of structs,
    >> expecially complex ones with embedded typedef'd unions.  Any helpful
    >> words of wisdom there.

    >
    >Same answer to any programming problem (or indeed any other sort
    >of problem) in which complexity threatens to overwhelm you. Modularise
    >(or divide and conquer).
    >
    >Hmm. Except I re-rwad your post. You say *typedefed unions*
    >confuse you. I use typedefs to reduce confusion.
    >
    >Initially I thought you were confused by
    >
    >typedef struct
    >{
    > char name [1024];
    > int serial_number;
    > int version;
    > int drive_type;
    > union drive /* syntax of union not-checked */
    > {
    > Sublight slow;
    > HyperDrive fast;
    > };
    >} Starship;
    >
    >and I was going to say lift the union out.
    >
    >typedef union
    >{
    > Sublight slow;
    > HyperDrive fast;
    >} StarshipDrive;
    >
    >typedef struct
    >{
    > char name [1024];
    > int serial_number;
    > int version;
    > int drive_type;
    > StarshipDrive drive;
    >} Starship;
    >
    >If I've misunderstood gould you give an example of what confuses
    >you?
    >

    Not quickly. May be quite a while. When i get one i will bring it
    around.
     
    JosephKK, Mar 13, 2009
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ryan Ternier
    Replies:
    0
    Views:
    342
    Ryan Ternier
    Jan 10, 2006
  2. David MacQuigg

    Is classless worth consideration

    David MacQuigg, Apr 29, 2004, in forum: Python
    Replies:
    33
    Views:
    883
    Erik Max Francis
    May 3, 2004
  3. steve yee

    about design consideration of strcpy()

    steve yee, May 25, 2006, in forum: C Programming
    Replies:
    13
    Views:
    487
    Charles Richmond
    May 26, 2006
  4. RGK
    Replies:
    4
    Views:
    331
  5. bpascal123
    Replies:
    6
    Views:
    347
    Keith Thompson
    Jun 6, 2011
Loading...

Share This Page