I'm having a problem doing what must be an ordinary, simple operation in C.

I have a large array, buf, through which I'm indexing with a pointer curptr,
a pointer to char.  I want to copy a string of bytes from the current
position of the pointer, to a different array of char (a string).
strncpy seems like a natural way to do it, but I can't convince C to
treat the point where my curptr points as a string.

Thanks,
Bob

    char buf[1310720];
    char *curptr;
    char savehead[80], savetail[80];
    char *saveptr[80];
...
while(END_FLAG != 1) {/* outer loop sends all records  */
    sendlen = 0;
    curptr = &buf[0];
    for (I=0; I<20; I++) {/* accumulate tape recs into large buffer */
        bytes = fread (curptr, 1, 65000, tape);
        if (feof(tape)) { END_FLAG=1; break; }
        sendlen += bytes;
        curptr += bytes;
    }
... send routine ...sends data to a TCP stream socket

            saveptr = curptr - lrecl;
/*complains that saveptr is not a modifiable lvalue */
            strncpy(savetail, *saveptr, sizeof(savetail));
Distribution: usa

--

Champaign, Illinois                217/356-2684

saveptr is a RValue pointer to an array of 80 pointers to char.  No, you
can't assign a value to it.  From what you've got here, you should change
your declaration of saveptr from

char *saveptr[80];

to

char *saveptr;

Then, in your strncpy, use

strncpy(savetail, saveptr, sizeof(savetail));

**Because**

When you make a declaration of the form

(type) (varname)[(arraysize)];

Then the (varname) is an RValue...a constant.  It points to a block of memory
that is assigned at compile time, and cannot be changed.
You have two choices for declaring a pointer as an LValue - a variable.  First,
you can leave out the (arraysize) to get

(type) (varname)[ ];

or you can declare pointer as above:

(type) *(varname);

Either version gives you a variable.

Dave

An array name is not an rvalue, and an array is not a constant.  An
array name in an rvalue context *acts like* a constant.

Those who wish to answer questions about pointers and arrays should
read and understand all of section 2 of the FAQ before beginning,
lest they find themselves confusing readers further.

This is just plain wrong.  This constant may be omitted only when the
declaration is for a formal parameter; see question 2.2.

This is correct.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc

: >
: >I'm having a problem doing what must be an ordinary, simple operation in C.
: >
: >I have a large array, buf, through which I'm indexing with a pointer curptr,
: >a pointer to char.  I want to copy a string of bytes from the current
: >position of the pointer, to a different array of char (a string).
: >strncpy seems like a natural way to do it, but I can't convince C to
: >treat the point where my curptr points as a string.
: >
: >Thanks,
: >Bob

Bob,
   I suggest using memcpy.

memcpy(str, curptr, strlen(curptr) + 1);

the +1 added to strlen allows it to copy the terminating NULL character.

strncpy is a strange beast which doesn't do what you might first expect. It
is generally best avoided unless it is *really* what you want (which is
rare). The simplest alternative is usually through strncat with something
like:
  #include <string.h>

  str[0] = '\0';
  strncat(str, cyrptr, n);

where n is the length of substring you want to extract. The target string
will always be correctly '\0' terminated when you do it this way.

sprintf can be a good way of dealing with more a more complex set of
operations.

But this is equivalent to simply

   strcpy(str, curptr);

Also be careful how you talk about NULL - in C it is a pointer constant,
not a character.

--
-----------------------------------------


-----------------------------------------

......
...

    I thought NULL was just a constant zero, not implicitly or explicitly
a pointer value. Correct me if I am wrong, if I make below statements
                int a=NULL;
                float b=NULL;
                float *c=NULL;
wouldn't all work.?

   They would all work ... for the following reason ...

   NULL is a pointer value, which must compare equal to zero. The normal
definition is

#define NULL    ((void *) 0)

   However, it is best to use NULL only for pointer values. NULL in C is
like nil in Pascal.

                                         _/_/_/_/
   _/_|  _/_|       _/_|     _/_/_/        _/_|     _/_/_/
  _/ _| _/ _|     _/  _|   _/            _/  _|   _/    _/
 _/  _|_/  _|   _/_/_/_|  _/   _/_/_/  _/_/_/_|  _/    _/
_/   _|    _| _/      _|  _/_/_/_/   _/      _|  _/_/_/

NULL is not necessarily the constant 0, it is a macro intended to
hold a value which will give a null pointer in a pointer context. And
yes, the only arithmetic value that accomplishes that is the value 0.
However, it may well be defined as

  #define NULL ((void*)0)

and since there is no guarantee that a null pointer shall be converted to
the value 0 (zero) when cast to an arithmetic type, there is no guarantee
that your first two initializations will have the same effect as

   int a = 0;
   float b = 0.0;

(which is what I suspect you had in mind). In fact, they will result in
either undefined results or undefined behaviour (I just can't remember
which). The macro NULL should only be used in pointer contexts. (In cases
where the compiler can't tell it is a pointer context, you should cast it
to the proper pointer type yourself. This case arises when you use K&R
style function definitions, functions of which no prototypes are in scope,
or variable length argument lists. Did I leave anything out? Oh well, I
knew I would.)

--
                                       ^^

University of Twente                 =x=  \        tel. +31 53 893747
Tele-Informatics & Open Systems        |   \       tfx. +31 53 333815
P.O. Box 217   7500 AE Enschede       /|__  \
The Netherlands                      (____)_/

ASHes to ASHes, DOS to DOS.

I think this is faulty argument. The implementation of the NULL value
is not fixed, ie

#define NULL ((void *) -1)

would be OK too.

Agreed, but seen other definitions too :)
--

X.400 (suomi) : GN=JKETO;OV1=CS;O=JOENSUU;ADMD=FUMAIL;C=FI
Tel           : +358 73 736210                            
Bread & Butter: Large scale c/c++/oracle/unix/client-server programs

No, it wouldn't.  It is *GUARANTEED* by the language that ANY AND ALL null
pointers evaluate equal to zero.  No such guarantee exists for -1, and I'm
informed that some people have used computers where '-1' (which, in their
machine's architecture, turned out to be a bunch of 1 bits set) was a valid
pointer.

malloc() returns NULL on failure.  It is *guaranteed* that
if (malloc(n)) will determine whether or not malloc failed (although it won't
save the pointer, so it's a bad thing.  Ditto for
if (malloc(n) != 0)
However,
if (malloc(n) != -1)
is NOT meaningful.

#define NULL 0
is correct, and sufficient.  It is also necessary that an unadorned constant
0 compare equal to the null pointer, and not equal to any valid pointer.

Read the first section of the FAQ again.  Although at the *machine* level,
it may well be that a null pointer constant is implemented as -1, you are
NOT able to assume that a -1 in code will match it.

-seebs
--

GAT(CS/M/P/SS) d-- H++ s+: !g p? !au a- w+++ v+++/* C++++ UB/V++++ P+ L b+++ !D
3+(NetBSD/Amiga) E- N+++ K !W--- M++/-- V- -po+ Y+ t 5++ jx R G'''' tv- B---
e++ u** h--- f+ r+++ !n x+++* --SeebS-- / The Laughing Prophet

Couldn't one express that as:

        strncpy(str, curptr, n);
        str[n] = '\0';

Or am I missing something subtle?

Lint complains that "strncpy returns value which is always ignored".
I can shut it up with

        (void) strncpy(str, curptr, n);
        str[n] = '\0';

or with

        strncpy(str, curptr, n)[n] = '\0';

or I can ignore lint.  What should I do?

--
HansM