Parsing a PATH null-terminated variable

R

Richard Bos

Eric Sosman said:
This is all right, but I dislike initializing variables with
values that will never be used: Your function will either set lvar
to something else, or will return without ever touching it, so this
initial value is useless. Yes, I know, some people think it's a
good idea to initialize every variable, especially every pointer
variable, but those people are mistaken. So Say I, The Authority
On Whose Word You Should Always Rely.

Regardless of whether you agree with Eric's comments above, at least
_never_ pre-initialise one of your objects, but not the others.
Whichever style you choose, be consistent with it.
Here's the reason for using a duplicate. But think a moment:
You know where the substring's first character is (at `t'), and you
know where the terminator is (at `p'), so you also know how long the
substring is (`p - t' characters). Instead of storing a '\0' just
so strcat() can find it again, why not just memcpy() the known number
of characters starting at `t'?

Or strncat(), which both copies only N characters _and_ appends the null
terminator.

Richard
 
C

Chris Torek

Historical precisions.

Reading DMR's "The development of the C Programming Language" in HOPL-II.
DMR's compiler seems to have been ported to Honeywell 635 and IBM 360/370.
Then Steve Johnson wrote pcc at the same time as he, dmr and Thompson
ported Unix to Interdata 8/32. The port induced changes in the language
(unsigned, cast, tying struct members to the struct).

Right. Before that point, you could get unsigned integers, by
using pointers (in dmr's original C compiler, pointers and integers
were freely interconvertible and one did things like 0177440->csr
to access hardware). There was no unsigned char or short, though.
Even "long" was a relatively late addition (V6 Unix used arrays of
two "int"s, hence the odd calling sequence for C's time() function).
The success of the port led another port to the VAX. (It isn't
mentioned if the VAX compiler was based on pcc or not -- which
makes me think it probably was).

It was. (Hence "two compilers".) PCC, the Portable C Compiler,
used a hand-written lexer, yacc to parse, and a table-driven code
generator (and an optional separate optimizer, "c2", written by
John Reiser, at least the VAX version). There were PCC back-ends
(i.e., tables) for at least the PDP-11, Interdata, and VAX (and
probably IBM 360, but I think Honeywell was never done, as the VAX
PCC rejected GECOS-style backquote constants, which never formally
made it into the C language either). More machines were added
later, when Unix got commercialized.

I never used or modified dmr's compiler, but it had a hand-written
recursive-descent parser and ad-hoc code generator.

I am not sure if there were several different "cpp" preprocessor
programs; the only one I ever dealt with was the Reiser version
(which, like c2, was nearly unmaintainable -- jfr's code was
atrocious).
 
R

Richard Bos

Eric Sosman said:
Wouldn't help in this case. The variables t and p point,
respectively, at the start of the substring to be copied and
at the ':' or '\0' that follows it. If he used strncat() as

strncat(path, t, p-t);

... he'd get the substring copied from t to path, but the
result would not be '\0'-terminated.

It would have to be, because according to 7.21.3.2: "A terminating null
character is always appended to the result."

Richard
 
R

Richard Bos

Eric Sosman said:
Richard said:
Eric Sosman said:
Richard Bos wrote: [...]
Or strncat(), which both copies only N characters _and_ appends the null
terminator.
Wouldn't help in this case. The variables t and p point,
respectively, at the start of the substring to be copied and
at the ':' or '\0' that follows it. If he used strncat() as

strncat(path, t, p-t);

... he'd get the substring copied from t to path, but the
result would not be '\0'-terminated.

It would have to be, because according to 7.21.3.2: "A terminating null
character is always appended to the result."

Oh, pfui! You're right, of course. In my pre-caffeinated
state I misread "strncat" as "strncpy" and blundered yet again.

One of the several reasons why strncpy() is /non grata/.
Think this'll teach me not to post before the coffee takes hold?
Probably not, alas ...

I recommend good tea instead. Not that it helps _me_ not blunder...

Richard
 
D

DiAvOl

Regardless of whether you agree with Eric's comments above, at least
_never_ pre-initialise one of your objects, but not the others.
Whichever style you choose, be consistent with it.

Actually I didn't initialize any variable in the first place (or first
version), I manipulated the var variable directly (char * by that time
no const keyword). Then I thought it would be a good idea to duplicate
the original value in case I need it later in my code, thus adding the
lvar = NULL pointer.

I am a relatively new C programmer (I did some projects in C though)
so I am not sure if it's better to initialize variables or not. I
think that if someone codes carefully and tests the function(s)
extensively both coding styles are equally good.

To return in my first question, do you consider this code ok ?

Thanks
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,188
Latest member
Crypto TaxSoftware

Latest Threads

Top