Andy Stewart <kb1...@polarismail.net> writes:

>>> adif3.c: In function ‘adif_qso_append’:
>>> adif3.c:527:4: error: ‘strncpy’ source argument is the same as destination 
>>> [-Werror=restrict]
>>>      strncpy (qfield, q[fld], qfield_len);  // Save the string from start 
>>> to space, not including the space.
>>>      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> POSIX says that strncpy with overlapping arguments is Undefined
>> Behavior:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/strncpy.html
>
> HI Greg et al,
>
> I don't see this warning when I compile on a 64-bit machine.

That doesnn't mean it's ok.  The real problem is not the warning, it's
code that leads to undefined beahvior.  The point of the UB in POSIX is
to admit implementations that don't work right for overlapping copies,
and I'd guess that's about allowing paralellism and in particular the
use of CPU instructions that do block copies but themselves are not
specified to work for overlap.  That's a typical CISC thing and I'm
pretty sure VAX and x86 have that sort of instruction.

With a variety of systems and compilers, we end up with greater coverage
for finding problems.

> I'm trying to code the equivalent of Perl's "chop" instruction.  Do
> you have any suggestions that will accomplish this operation AND keep
> the compiler sated?

I'm having trouble following what's there, but as I read it the strncpy
call is indeed invalid because qfield always equals q[fld] when it
happens.

I think the point is to modify q[fld], so I would write the code to do
that directly rather than via a variable that points to it, but that's
not important.

I also find the space_ptr bit confusing as it made me think this was
looking for a second space, instead of just

                  space_ptr = strpbrk (q[fld], " ");

As I see it  this line

                        qfield[qfield_len] = '\0';             // Null 
terminate the desired string                                                    
          

is sufficient because it sets the space to \0, thus ending the string.
The previous strncpy just copied the part you are keeping to itself.

It would be nice to check field_len against the allocated storage for
the field before writing based on it, but pretty clearly this is ok or
there'd have been reports.


(I finally get it that the point is just to get rid of " deg" at the
end, and that this is done by dropping the first space and everything
following.  So it will do semi-random things on malformed data, but will
do the right thing on ok data.)

Also if you are looking for space only, strchr is simpler.  I had not
previously run into strpbrk but I see it's part of C89.  But the usage
strpbrk of looks correct to me, now that I've read the spec.

Attachment: signature.asc
Description: PGP signature

Reply via email to