programi parsing question - Unix

This is a discussion on programi parsing question - Unix ; K-mart Cashier wrote: > if((fd = open(_PATH_UTMP, O_RDONLY)) > > is a common found in both "The C Programming Language" by K & R and > the FreeBSD source code. If they all just jumped off a cliff, would you? ...

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 113

Thread: programi parsing question

  1. Re: programi parsing question

    K-mart Cashier wrote:

    > if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
    >
    > is a common found in both "The C Programming Language" by K & R and
    > the FreeBSD source code.


    If they all just jumped off a cliff, would you?

    Seriously, the style is a legacy of days when C could not initialize reliably.
    The style's only redeeming characteristic is you only need to read the big words
    - "if open PATH_UTMP", and you can scan over the rest and know by sight-reading
    they are the common open-a-file-and-fail-gracefully idiom.

    > What's the difference between printf("%s\n", line) and
    > printf("%.*s",...) ?


    I already illustrated the * - it might limit the string to the number of bytes
    specified before it in the ... part.

  2. Re: programi parsing question

    Phlip writes:

    > fjblurt@yahoo.com wrote:
    >
    >> But other than that it looks like it should work. Note I still think
    >> that printf("%.*s",...) is nicer.

    >
    > Is the dot supposed to be there? What's it do?


    Yes. See my other post.

    --
    Ben.

  3. Re: programi parsing question

    Phlip said:

    > fjblurt@yahoo.com wrote:
    >
    >> But other than that it looks like it should work. Note I still think
    >> that printf("%.*s",...) is nicer.

    >
    > Is the dot supposed to be there?


    Yes.

    > What's it do?


    4.9.6.1 the fprintf function

    [...]

    * An optional precision that gives the minimum number of digits to
    appear for the d , i , o , u , x , and X conversions, the number of
    digits to appear after the decimal-point character for e , E , and f
    conversions, the maximum number of significant digits for the g and G
    conversions, or the maximum number of characters to be written from a
    string in s conversion. The precision takes the form of a period (.)
    followed by an optional decimal integer; if the integer is
    omitted, it is treated as zero.

    [...]

    A field width or precision, or both, may be indicated by an
    asterisk * instead of a digit string. In this case, an int argument
    supplies the field width or precision.


    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  4. Re: programi parsing question

    On Aug 5, 7:39 am, Phlip wrote:
    > K-mart Cashier wrote:
    > > int main(void)
    > > {
    > > int fd;
    > > struct utmp log;
    > > char line[UT_LINESIZE + 1];

    >
    > > if((fd = open(_PATH_UTMP, O_RDONLY)) < 0){
    > > fprintf(stderr, "can't open file\n");
    > > exit(1);
    > > }

    >
    > C literature often shows a penchant for cramming lines together. I would have
    > gone with:
    >
    > struct utmp log = {0};
    > int fd = open(_PATH_UTMP, O_RDONLY);
    >
    > if(fd < 0){
    > fprintf(stderr, "can't open file\n");
    > exit(1);
    > }
    >
    > Next, isn't fd well-defined as -1 if open() fails?
    >
    > Next, I would pass _PATH_UTMP into the "can't open file" line, to give the user
    > a clue _what_ file can't open.
    >
    > > while(read(fd, &log, sizeof(log)) == sizeof(log)){

    >
    > assert(log.ut_name[UT_LINESIZE - 1] == 0);
    >
    > > strncpy(line, log.ut_name, UT_NAMESIZE);
    > > line[UT_LINESIZE] = '\0';
    > > printf("%s\n", line);
    > > }

    >
    > Does my assertion work? If I had invented this UTMP system, I would enforce a
    > well-defined '\0' at the end of a line. Sometimes APIs shouldn't do that.
    >
    > If this API does not, then my -1 is incorrect, and your +1 is correct. But
    > couldn't you use
    >
    > printf("%*s\n", UT_LINESIZE, log.ut_name);
    >
    > to avoid the extra buffer and copy?
    >


    One last question. Does something like

    line[UT_NAMESIZE] = '\0';

    initialize each element in the array with '\0' or does it just
    initialize the last element in the array? According to my debugger,
    all the elments in line get initialized with '\0's Do I believe my
    compiler in this case?



  5. Re: programi parsing question

    On Aug 5, 7:19 pm, K-mart Cashier wrote:
    > On Aug 5, 7:39 am, Phlip wrote:
    >
    >
    >
    > > K-mart Cashier wrote:
    > > > int main(void)
    > > > {
    > > > int fd;
    > > > struct utmp log;
    > > > char line[UT_LINESIZE + 1];

    >
    > > > if((fd = open(_PATH_UTMP, O_RDONLY)) < 0){
    > > > fprintf(stderr, "can't open file\n");
    > > > exit(1);
    > > > }

    >
    > > C literature often shows a penchant for cramming lines together. I would have
    > > gone with:

    >
    > > struct utmp log = {0};
    > > int fd = open(_PATH_UTMP, O_RDONLY);

    >
    > > if(fd < 0){
    > > fprintf(stderr, "can't open file\n");
    > > exit(1);
    > > }

    >
    > > Next, isn't fd well-defined as -1 if open() fails?

    >
    > > Next, I would pass _PATH_UTMP into the "can't open file" line, to give the user
    > > a clue _what_ file can't open.

    >
    > > > while(read(fd, &log, sizeof(log)) == sizeof(log)){

    >
    > > assert(log.ut_name[UT_LINESIZE - 1] == 0);

    >
    > > > strncpy(line, log.ut_name, UT_NAMESIZE);
    > > > line[UT_LINESIZE] = '\0';
    > > > printf("%s\n", line);
    > > > }

    >
    > > Does my assertion work? If I had invented this UTMP system, I would enforce a
    > > well-defined '\0' at the end of a line. Sometimes APIs shouldn't do that.

    >
    > > If this API does not, then my -1 is incorrect, and your +1 is correct. But
    > > couldn't you use

    >
    > > printf("%*s\n", UT_LINESIZE, log.ut_name);

    >
    > > to avoid the extra buffer and copy?

    >
    > One last question. Does something like
    >
    > line[UT_NAMESIZE] = '\0';
    >
    > initialize each element in the array with '\0' or does it just
    > initialize the last element in the array? According to my debugger,
    > all the elments in line get initialized with '\0's Do I believe my
    > compiler in this case?



    Correction. Do I believe my debugger in this case?

  6. Re: programi parsing question

    K-mart Cashier said:



    >> One last question. Does something like
    >>
    >> line[UT_NAMESIZE] = '\0';
    >>
    >> initialize each element in the array with '\0' or does it just
    >> initialize the last element in the array?


    Neither, since it's not - strictly speaking - an initialisation, merely an
    assignment. And it only assigns a value to line[UT_NAMESIZE], not to any
    other element.

    >> According to my debugger,
    >> all the elments in line get initialized with '\0's Do I believe my
    >> compiler in this case?


    Since you don't specify values for the other elements in the array, the
    compiler can make them whatever it likes...

    > Correction. Do I believe my debugger in this case?


    ....and so can the debugger.

    Had your definition included an initialisation:

    char line[UT_NAMESIZE + 1] = {0};

    my answer would have been rather different, because the default static
    initialisation rules would have cut in.

    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  7. Re: programi parsing question

    Crossposting this to comp.lang.c because it's become relevant.

    Our story so far, for c.l.c people:

    There is a discussion about the stylistic advantages and disadvantages
    of the following two snippets:

    void foo (void) {
    int fd;
    if ((fd = open(...)) < 0) {
    fail();
    }
    }

    versus

    void foo (void) {
    int fd = open(...);
    if (fd < 0) {
    fail();
    }
    }

    Phlip prefers the latter, and claims that the former gained popularity
    because early versions of C did not guarantee the order in which
    initializations occurred, or had other problems, and therefore
    initializations in declarations were discouraged.

    On Aug 5, 6:22 pm, Phlip wrote:
    > K-mart Cashier wrote:
    > > if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)

    >
    > > is a common found in both "The C Programming Language" by K & R and
    > > the FreeBSD source code.

    >
    > If they all just jumped off a cliff, would you?
    >
    > Seriously, the style is a legacy of days when C could not initialize reliably.


    Do you have a specific example? K&R, first edition, doesn't seem to
    address the issue of order specifically, but does say (appendix A,
    section 8.6): "Automatic or register variables may be initialized by
    arbitrary expressions involving constants, and previously declared
    variables and functions." This would seem to imply that previously
    declared variables would already have been initialized.

    On the other hand, section 4.9 gives two examples:

    binary(x, v, n)
    int x, v[], n;
    {
    int low = 0;
    int high = n - 1;
    int mid;
    ...
    }

    and

    binary(x, v, n)
    int x, v[], n;
    {
    int low, high, mid;

    low = 0;
    high = n - 1;
    ...
    }

    and then goes on to say:

    "In effect, initializations of automatic variables are just shorthand
    for assignment statements. Which form to prefer is largely a matter
    of taste. We have generally used explicit assignments, because
    initializers in declarations are harder to see."

    So it would appear that the reason K&R avoid using initializers was
    not because there was something wrong with the way they worked, but
    just for stylistic reasons, because they thought it was more readable
    that way. (I tend to agree.)

    For an assignment like our example that involves a nontrivial function
    call, I think most people would not expect to see it in an
    initializer, because oftentimes nontrivial function calls will require
    more computations to be done first, even though this example happens
    not to.

    So that leaves us the choice of

    int fd;
    ....
    if ((fd = open(...)) < 0) fail();

    or

    int fd;
    ....
    fd = open(...);
    if (fd < 0) fail();

    and the latter needs an extra line.

    C99 gives us the option not to declare fd until just before we need
    it, so we could write

    .... lots of stuff ...
    int fd = open(...);
    if (fd < 0) fail();

    but *that* is a relatively recent invention, and not necessarily
    universally available.

    > The style's only redeeming characteristic is you only need to read the big words
    > - "if open PATH_UTMP", and you can scan over the rest and know by sight-reading
    > they are the common open-a-file-and-fail-gracefully idiom.


    That's a significant advantage, IMHO.

  8. Re: programi parsing question

    fjblurt@yahoo.com wrote:
    >
    > Crossposting this to comp.lang.c because it's become relevant.
    >
    > Our story so far, for c.l.c people:
    >
    > There is a discussion about the stylistic advantages and
    > disadvantages of the following two snippets:
    >
    > void fooA(void) {
    > int fd;
    > if ((fd = open(...)) < 0) {
    > fail();
    > }
    > }
    >
    > versus
    >
    > void fooB(void) {
    > int fd = open(...);
    > if (fd < 0) {
    > fail();
    > }
    > }


    Considering the crosspost, I won't complain about using the
    non-standard open in place of fopen. However it is inappropriate
    on comp.programming.

    I have renamed the two functions. I consider fooA superior. I
    disapprove of initialization code more complex than a simple value,
    such as 0, and discourage even that. fooB must generate a call to
    open, so it must generate code for that. That code is hidden from
    the reader.

    The only place, IMO, where initialization code is justified is
    where the variable has the const characteristic applied. Then it
    is necessary to install a value.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.


  9. Re: programi parsing question

    CBFalconer wrote:
    > fjblurt@yahoo.com wrote:


    >> void fooB(void) {
    >> int fd = open(...);
    >> if (fd < 0) {
    >> fail();
    >> }
    >> }

    >
    > Considering the crosspost, I won't complain about using the
    > non-standard open in place of fopen. However it is inappropriate
    > on comp.programming.


    You surely mean comp.lang.c?




  10. Re: programi parsing question

    CBFalconer wrote:

    > I have renamed the two functions. I consider fooA superior. I
    > disapprove of initialization code more complex than a simple value,
    > such as 0, and discourage even that.


    You're bonkers.

    Why /not/ initialise a variable when you declare it, with the value
    you want it to have?

    --
    'It changed the future .. and it changed us.' /Babylon 5/

    Hewlett-Packard Limited Cain Road, Bracknell, registered no:
    registered office: Berks RG12 1HN 690597 England


  11. Re: programi parsing question

    Chris Dollin wrote:

    > CBFalconer wrote:
    >
    >> I have renamed the two functions. I consider fooA superior. I
    >> disapprove of initialization code more complex than a simple value,
    >> such as 0, and discourage even that.

    >
    > You're bonkers.
    >
    > Why /not/ initialise a variable when you declare it, with the value
    > you want it to have?


    If the initialisation can take place close to the actual use, then it
    makes good sense, otherwise I see no added benefit in initialising
    something at line N, then testing it further or proceeding to use at
    line N+50.


  12. Re: programi parsing question

    In article <0551f772-ee4e-42f3-a791-a745e44d1ad2@b38g2000prf.googlegroups.com>
    wrote:
    >There is a discussion about the stylistic advantages and disadvantages
    >of the following two snippets:


    [I did some editing in the quotes below, to be able to talk about
    them better later.]

    >void foo_set_and_test (void) {
    > int fd;
    > if ((fd = open(...)) < 0) {
    > fail();
    > }
    >}
    >
    >versus
    >
    >void foo_init_and_then_test_separately (void) {
    > int fd = open(...);
    > if (fd < 0) {
    > fail();
    > }
    >}
    >
    >Phlip prefers the latter, and claims that the former gained popularity
    >because early versions of C did not guarantee the order in which
    >initializations occurred,


    As far as I know, no version of C, no matter how early and
    not-even-K&R-1-compliant, did initializations in any order other
    than "as they appear in the source". So:

    void func(void) {
    int a = init_a();
    char *b = init_b();
    double c = init_c(), d = init_d();
    ...
    }

    will always call init_a() first, then init_b(), then init_c(), then
    init_d(), even in truly ancient implementations.

    I have a slight preference for foo_init_and_then_test_separately()
    myself, but this is a matter of taste. There is even a third
    option:

    void foo_set_and_then_test_separately(void) {
    int fd;

    fd = open(...);
    if (fd < 0) {
    fail();
    ...
    }
    ...
    }

    which I slightly prefer over foo_init_and_then_test_separately()
    (but only *very* slightly).

    >[K&R-1] then goes on to say:
    >
    >"In effect, initializations of automatic variables are just shorthand
    >for assignment statements. Which form to prefer is largely a matter
    >of taste. We have generally used explicit assignments, because
    >initializers in declarations are harder to see."
    >
    >So it would appear that the reason K&R avoid using initializers was
    >not because there was something wrong with the way they worked, but
    >just for stylistic reasons, because they thought it was more readable
    >that way. (I tend to agree.)


    As do I -- and I separate out the assignment and test when possible
    as well, for the same reason. I will cram them together in
    some cases, such as inside the control expression of a loop:

    while ((c = getchar()) != EOF) {
    ...
    }

    because, while this is a bit hard to read, it is still easier to
    read than the two obvious alternatives:

    c = getchar();
    while (c != EOF) {
    ...
    c = getchar();
    }

    (which duplicates the "get a character" action, creating opportunities
    for getting things wrong during code maintenance -- perhaps getchar()
    needs to be replaced by get_from_file_while_maintaining_line_number()
    or similar; and "continue" inside the loop is now bad), or:

    while (c = getchar(), c != EOF) {
    ...
    }

    (which is readable but unusual, and requires duplicating the variable
    name). If this last alternative were more commonly found in other
    C code, I might use it, so this particular preference is more
    historical than anything else.

    Again, though, all of this is largely a matter of taste. Arguing
    about it is like arguing whether raspberry ice cream is superior
    to peach ice cream. (Answer: neither, chocolate is better :-) )
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
    email: gmail (figure it out) http://web.torek.net/torek/index.html

  13. Re: programi parsing question

    Chris Torek wrote:
    > In article
    > <0551f772-ee4e-42f3-a791-a745e44d1ad2@b38g2000prf.googlegroups.com>
    > wrote:




    >>[K&R-1] then goes on to say:
    >>
    >>"In effect, initializations of automatic variables are just shorthand
    >>for assignment statements. Which form to prefer is largely a matter
    >>of taste. We have generally used explicit assignments, because
    >>initializers in declarations are harder to see."
    >>
    >>So it would appear that the reason K&R avoid using initializers was
    >>not because there was something wrong with the way they worked, but
    >>just for stylistic reasons, because they thought it was more readable
    >>that way. (I tend to agree.)

    >
    > As do I -- and I separate out the assignment and test when possible
    > as well, for the same reason. I will cram them together in
    > some cases, such as inside the control expression of a loop:
    >
    > while ((c = getchar()) != EOF) {
    > ...
    > }
    >
    > because, while this is a bit hard to read, it is still easier to
    > read than the two obvious alternatives:
    >
    > c = getchar();
    > while (c != EOF) {
    > ...
    > c = getchar();
    > }
    >
    > (which duplicates the "get a character" action, creating opportunities
    > for getting things wrong during code maintenance -- perhaps getchar()
    > needs to be replaced by get_from_file_while_maintaining_line_number()
    > or similar; and "continue" inside the loop is now bad), or:
    >
    > while (c = getchar(), c != EOF) {
    > ...
    > }
    >
    > (which is readable but unusual, and requires duplicating the variable
    > name).


    One other possibility:

    for (c = getchar(); c != EOF; c = getchar()) { ... }

    In general I have found that code consisting of (as far as is feasible)
    simple expressions is better adaptable to restructuring and change than
    code with lot of complex expressions. It's much like taking apart a car
    made of Lego blocks versus a real one. Of course all code can't use
    Lego blocks, but where possible...




  14. Re: programi parsing question

    On Aug 6, 2:11 am, Chris Dollin wrote:
    > CBFalconer wrote:
    > > I have renamed the two functions. I consider fooA superior. I
    > > disapprove of initialization code more complex than a simple value,
    > > such as 0, and discourage even that.

    >
    > You're bonkers.
    >
    > Why /not/ initialise a variable when you declare it, with the value
    > you want it to have?
    >


    Because they're veterans who still declare a hundred variables at the
    top

    Sebastian


  15. Re: programi parsing question

    Chris Dollin wrote:
    > CBFalconer wrote:
    >
    >> I have renamed the two functions. I consider fooA superior. I
    >> disapprove of initialization code more complex than a simple value,
    >> such as 0, and discourage even that.

    >
    > You're bonkers.
    >
    > Why /not/ initialise a variable when you declare it, with the value
    > you want it to have?


    If you want hidden code, try C++. You will be adequately served.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.



  16. Re: programi parsing question

    Chris Torek writes:
    > wrote:
    >>There is a discussion about the stylistic advantages and disadvantages
    >>of the following two snippets:


    [...]

    >>void foo_set_and_test (void) {
    >> int fd;
    >> if ((fd = open(...)) < 0) {
    >> fail();
    >> }
    >>}


    [...]

    >>void foo_init_and_then_test_separately (void) {
    >> int fd = open(...);
    >> if (fd < 0) {
    >> fail();
    >> }
    >>}


    [...]

    > I have a slight preference for foo_init_and_then_test_separately()
    > myself, but this is a matter of taste. There is even a third
    > option:
    >
    > void foo_set_and_then_test_separately(void) {
    > int fd;
    >
    > fd = open(...);
    > if (fd < 0) {
    > fail();
    > ...
    > }
    > ...
    > }


    [...]

    > Again, though, all of this is largely a matter of taste. Arguing
    > about it is like arguing whether raspberry ice cream is superior
    > to peach ice cream.


    The last (two) variant(s) has(ve) the advantage that the value
    assigned to fd can be inspected and possibly changed by a human using
    a 'suitable tool' (debugger) before the program acts on it.

  17. Re: programi parsing question

    Rainer Weikusat wrote:

    > Chris Torek writes:


    >> int fd;
    >> fd = open(...);


    >> Again, though, all of this is largely a matter of taste. Arguing
    >> about it is like arguing whether raspberry ice cream is superior
    >> to peach ice cream.


    > The last (two) variant(s) has(ve) the advantage that the value
    > assigned to fd can be inspected and possibly changed by a human using
    > a 'suitable tool' (debugger) before the program acts on it.


    I suspect there are style guidelines saying "always initialize every variable".
    Maybe they only apply to C++, and C is exempt.

    --
    Phlip

  18. Re: programi parsing question

    Phlip wrote:

    > Rainer Weikusat wrote:
    >
    >> Chris Torek writes:

    >
    >>> int fd;
    >>> fd = open(...);

    >
    >>> Again, though, all of this is largely a matter of taste. Arguing
    >>> about it is like arguing whether raspberry ice cream is superior
    >>> to peach ice cream.

    >
    >> The last (two) variant(s) has(ve) the advantage that the value
    >> assigned to fd can be inspected and possibly changed by a human using
    >> a 'suitable tool' (debugger) before the program acts on it.

    >
    > I suspect there are style guidelines saying "always initialize every
    > variable". Maybe they only apply to C++, and C is exempt.


    That cannot be, unless C forbids initialising every variable, which it
    doesn't. In the dim and distant past I suppose variable redundant
    initialisations were avoided due to efficiency concerns. These no
    longer matter now, but some still prefer to avoid redundant
    initialisations as an aesthetic choice.


  19. Re: programi parsing question

    Phlip wrote:
    ) I suspect there are style guidelines saying "always initialize every variable".
    ) Maybe they only apply to C++, and C is exempt.

    On the other hand, explicitly not initializing variables give static code
    analyzers the chance to find uses of uninitialized variables. (As opposed
    to uses of default-but-wrong-initialized values).


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT

  20. Re: programi parsing question

    Phlip wrote:
    > Eric Sosman wrote:
    >
    >>> AFAIK C cannot define the order those = initializations take.

    >>
    >> Section 6.2.4 paragraph 5 of the C Standard makes so bold
    >> as to do so ...

    >
    > Yay. Some pre-Standard Cs could not even initialize, and some could only
    > initialize constants, so maybe I'm recalling the Good Old Days...


    I think you must mean the Very Old Days. The original K&R
    came out thirty years ago, and specified initialization in
    declaration order for `auto' and `register' variables. Maybe
    the compilers you used prior to 1978 implemented an older version
    of the language?

    --
    Eric.Sosman@sun.com

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast