programi parsing question - Unix

This is a discussion on programi parsing question - Unix ; Phlip writes: > santosh wrote: >> I'm rather surprised that you classify Java as a "hard" language. > > This is what happens when someone cross-posts between two technical > newsgroups - the introductions go around! This is especially what ...

+ Reply to Thread
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 113

Thread: programi parsing question

  1. Re: programi parsing question

    Phlip writes:
    > santosh wrote:
    >> I'm rather surprised that you classify Java as a "hard" language.

    >
    > This is what happens when someone cross-posts between two technical
    > newsgroups - the introductions go around!


    This is especially what is going to happen when cross-posting between
    topically technical and topically talkative newsgroups.

    [...]

    > Further, Java uses static typing, which tends to require a huge number
    > of extra lines just to "fill out forms" and prove that various objects
    > have the right to interact with each other.


    The proponents of this approach would usually argue that their
    programs are already working, while you are still trying to find all
    places where you inadvertently swapped two arguments to some
    subroutine and - apart from that - that you will never find all of
    these instances, which means that your 'useful website' (contradiction
    in adiecto?) will suddenly turn into a pocket calculator at some really
    inconvenient time. The idea behind this type of discussion is to only
    talk about what one considers to be the strengths of what is supposed
    to advocated and only talks about what one considers to be the
    weaknesses of what is supposed to be put down.

    It's a freaking waste of time, except if the idea is to sell different
    refrigerators.

    F'up2p

  2. Re: programi parsing question

    Phlip writes:
    > santosh wrote:
    >> I'm rather surprised that you classify Java as a "hard" language.

    >
    > This is what happens when someone cross-posts between two technical
    > newsgroups - the introductions go around!


    This is especially what is going to happen when cross-posting between
    topically technical and topically talkative newsgroups.

    [...]

    > Further, Java uses static typing, which tends to require a huge number
    > of extra lines just to "fill out forms" and prove that various objects
    > have the right to interact with each other.


    The proponents of this approach would usually argue that their
    programs are already working, while you are still trying to find all
    places where you inadvertently swapped two arguments to some
    subroutine and - apart from that - that you will never find all of
    these instances, which means that your 'useful website' (contradictio
    in adiecto?) will suddenly turn into a pocket calculator at some really
    inconvenient time. The idea behind this type of discussion is to only
    talk about what one considers to be the strengths of what is supposed
    to advocated and only talks about what one considers to be the
    weaknesses of what is supposed to be put down.

    It's a freaking waste of time, except if the idea is to sell different
    refrigerators.

    F'up2p

  3. Re: programi parsing question

    On Aug 2, 9:42 pm, K-mart Cashier wrote:
    > On Aug 2, 9:36 pm, fjbl...@yahoo.com wrote:
    > > On Aug 2, 7:27 pm, K-mart Cashier wrote:
    > > > Now that I think about it, I have a second question. How come doesn't
    > > > get checked for a return value (on error)?

    >
    > > How come *what* doesn't get checked?

    >
    > memset()


    memset() can't fail (*), unless you point it to memory that isn't
    accessible. In that case you will get a segfault instead of an error
    return. If memset() explicitly checked whether its memory was
    accessible, it would be so slow that nobody would use it. So the
    return value is always equal to the pointer given. It doesn't contain
    any new information, it's just done because it's sometimes
    convenient. For example, you can do

    write(fd, memset(buf, 'X', 100), 100);

    in one line instead of two. Not really a big deal.

    (*) Upon rereading that phrase, I now have it stuck in my head to the
    tune of the Clash's "Rudy Can't Fail".

  4. Re: programi parsing question

    In comp.unix.programmer Phlip wrote:
    | santosh wrote:
    |
    |> I'm rather surprised that you classify Java as a "hard" language.
    |
    | This is what happens when someone cross-posts between two technical newsgroups -
    | the introductions go around!
    |
    | Java is amazingly hard, despite its brochure. To get a useful project going,
    | like a website, you often find yourself managing a thousand lines of
    | configuration, spread out over several files, before finally clawing your way to
    | the "hello, world".

    Java would not be my first choice for a hello world program. I'm sure such
    a program has been done in every language. I'm sure you can find quite many
    done in Java.

    Lacking other languages in the same class, I'd choose Java over C only for
    very large "enterprise class" projects involving 20,000 lines of code or more.


    | Further, Java uses static typing, which tends to require a huge number of extra
    | lines just to "fill out forms" and prove that various objects have the right to
    | interact with each other.

    It's a very "formal" language. It's a poor choice for "one off" programs,
    but programmers with experience in Java and not much in others could still
    choose Java even for little things and do better than if they switched to
    some other language.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  5. Re: programi parsing question

    In comp.unix.programmer Rainer Weikusat wrote:

    | I don't think that people who consider 'programming language grammar
    | and syntax' to be 'a really hard problem' will ever write a useful
    | program. That would be close to expecting first-graders struggling
    | with expressing themselves in writing to publish enlightening treaties
    | on epistemology. Programming languages are tools (or toys :-). The
    | world is a complex thing and most of the (unsolved) problems that
    | spring from it are hard problems in their own right. Solving them
    | requires use of suitable tools, not necessarily familiar ones.

    I don't doubt there are problems where the familiarity of the tool is
    overshadowed by the suitability of the tool. The lack of familiarity
    with a tool can impose the cost of becoming familiar to some degree
    based on what the problem is (I can't think of a case where it would
    not). I happen to be unfamiliar with Java and barely familiar with
    Perl. I could write a hello world program far faster in C simply
    because I am familar with it. What I need to code instantly comes to
    mind. I've even done it w/o using any library (directly generated
    syscalls in Linux). The time it takes is the time to type it.

    I will say that for _most_ programs one will typically do, the familiar
    language has a substantial advantage, and that advantage may or may not
    be overcome by the advantage a more suitable language has. One factor
    here is that suitability is generally a consistent attribute, whereas
    familiarity is not only different per programmer, but also different in
    time for the same programmer (who finally decides to learn something new).

    BTW, what turned me _off_ of using Java for web development was not the
    language itself. Instead, it was the administrative costs of configuring
    the applications to run in a Java environment, based on examples I saw in
    a book about Java for web applications. The amount of stuff to configure,
    and to learn about to make the correct configuration choices, and to know
    to be able to debug issues, was just way too huge. I prefer the KISS
    approach.

    I tried programming in Perl once. It was a very bad experience. Things
    just didn't work as expected. After spending 3 weeks on a project in Perl,
    I coded it up in C in 2 days (about 1000 lines of code), and had it working
    in 2 more days. I also was able to do things that Perl, at least at that
    time, could not do (memory mapping a large read-only data file so that many
    instances running at the same time would not be keeping private copies of
    the data, which was 300MB on a 512MB Sparc 10). Response times over the
    company LAN were perceptibly instantaneous. It rolled into production in
    5 weeks. The biggest delay in the project was getting management approval
    to buy a program to generate ZIP files, as no suitable FOSS one existed at
    that time (1996), and only one vendor had one for Solaris (where that was
    to be run).

    I have avoided Perl ever since. It is just to eclectic for me.

    I never took the (believed to be huge) plunge into Java (but I know
    programmers who do Java well). I've done some PHP, but I find it to be
    a bit "too soft". I tried a little Python, but chose not to plunge into
    that at least for now. If I needed to code up a large project now, I'd
    probably use Pike. But I have used Pike even for small "one off" programs
    and it seems to scale well. But I still use C for most things because of
    the 26 year familiarity factor boosted by having done assembly for 10
    years before that. I _think_ in terms of the model that C and assembly
    mostly share. C is not exactly how I would have designed an ideal
    language, but it is fairly close.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  6. Re: programi parsing question

    phil-news-nospam@ipal.net wrote:

    [Followups set to comp.programming, since this is OT for
    comp.unix.programmer]



    > Java would not be my first choice for a hello world program.


    I would agree with this. I have had some experience in beginner classes
    for both C and Java and I have observed students get remarkably up to
    speed in the former, while many were still struggling with the concept
    of class files and bytecode far longer than they should have, with the
    latter.

    However, once the core elements of both language are learnt, it becomes
    faster to produce to produce a complete application in Java than in C,
    when that application makes use of diverse functionality like
    networking, GUI etc. This is a direct consequence of Java including
    prepackaged support for these tasks, while with C, you need to search
    for the appropriate library and learn it's interface and
    idiosyncrasies.



    > Lacking other languages in the same class, I'd choose Java over C only
    > for very large "enterprise class" projects involving 20,000 lines of
    > code or more.


    I can see your point, though I wouldn't make such a decision based on
    consideration of LoC alone.




  7. Re: programi parsing question

    > Java would not be my first choice for a hello world program. I'm sure such
    > a program has been done in every language. I'm sure you can find quite many
    > done in Java.


    I refer to the "integration hell" spawned by systems like Tomcat.

    http://c2.com/cgi/wiki?IntegrationHell

    > Lacking other languages in the same class, I'd choose Java over C only for
    > very large "enterprise class" projects involving 20,000 lines of code or more.


    Which is exactly where Java goes crazy - the big projects that could have been
    small...

  8. Re: programi parsing question

    > Java would not be my first choice for a hello world program. I'm sure
    > such
    > a program has been done in every language. I'm sure you can find
    > quite many
    > done in Java.


    I refer to the "configuration hell" spawned by systems like Tomcat:

    http://c2.com/cgi/wiki?ConfigurationHell

    > Lacking other languages in the same class, I'd choose Java over C only
    > for
    > very large "enterprise class" projects involving 20,000 lines of code
    > or more.


    Which is exactly where Java goes crazy - the big projects that could
    have been small...

    (But I will no longer compare languages in this thread!)

  9. Re: programi parsing question

    phil-news-nospam@ipal.net writes:
    > In comp.unix.programmer Rainer Weikusat wrote:
    >
    > | I don't think that people who consider 'programming language grammar
    > | and syntax' to be 'a really hard problem' will ever write a useful
    > | program. That would be close to expecting first-graders struggling
    > | with expressing themselves in writing to publish enlightening treaties
    > | on epistemology. Programming languages are tools (or toys :-). The
    > | world is a complex thing and most of the (unsolved) problems that
    > | spring from it are hard problems in their own right. Solving them
    > | requires use of suitable tools, not necessarily familiar ones.
    >
    > I don't doubt there are problems where the familiarity of the tool is
    > overshadowed by the suitability of the tool. The lack of familiarity
    > with a tool can impose the cost of becoming familiar to some degree
    > based on what the problem is (I can't think of a case where it would
    > not). I happen to be unfamiliar with Java and barely familiar with
    > Perl. I could write a hello world program far faster in C simply
    > because I am familar with it.


    And how often have you been writing 'Hello, world'-programs because of
    an externally imposed requirement ('job') to do so lately? Not very
    often, I guess. The point I was trying to make is that a particular
    programming language is usually a non-negotiable part of some set of
    technical requirements. Eg, I ocassionally need to do modifications to
    a web portal which has been written in procedural PHP4 and it doesn't
    matter the least if $random_fashionable_language would initially have
    been the better choice. In a similar fashion, when I have to solve
    some so-called 'low-level' programming problem for 'our' device
    platform, the code will either be ARM9 assembly or C, because the
    devices have an ARM926SEJ-CPU and run a Linux (2.4) kernel.

    Given the unholy amount of existing (OSS) software written in C which
    is lying around everywhere, I doubt that someone can seriously work on
    general 'programming tasks' without having a good, working knowledge
    of C. Not writing something from scratch in Java (here chosen because
    'rewrite the world' is apparently very popular among Java-confined
    people), but adapating existing C code to a new task is going to be
    easier and faster and will lead to a higher quality product just
    because most parts of the existing code have already been debugged (by
    someone else).

    In some moderately distant past, I needed to interact with a
    Postscript-interpreter, so I learnt (and forgot :-) Postscript.


  10. Re: programi parsing question

    On Aug 2, 11:27 pm, gor...@hammy.burditt.org (Gordon Burditt) wrote:
    > >> >In the following code snippet, I misplaced one of the parenthesis in
    > >> >read() and as a result, the program outputs junk. The question is why
    > >> >does the misplaced parenthesin read() cause the program to print junk?
    > >> >I guess I probably don't understand how read() gets parsed or read in
    > >> >by the compiler

    >
    > >> The length argument to read() was the constant 1, as others have
    > >> pointed out.

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

    >
    > >> /* parens fixed above */

    >
    > >> > printf("%s\n", log.ut_user);
    > >> > }

    >
    > My system (FreeBSD) seems to have a ut_name, not a ut_user structure
    > member.
    >
    > >> HOWEVER, even if that problem is corrected, I see no guarantee that
    > >> what is read is '\0'-terminated. read() makes no such guarantee,
    > >> and I doubt that the file format does either. Ensure that strings
    > >> are terminated before trying to print them with %s.

    >
    > >So should I have done something like

    >
    > >memset(&log, 0, sizeof (log));

    >
    > >before the call to read()?

    >
    > That is insufficient. Consider a system in which the administrator
    > insists that all names (well, perhaps not including root) MUST be
    > UT_NAMESIZE characters long (NOT including the '\0', because there
    > isn't room for one) to make them hard to guess.
    >
    > This is one application where strncpy() can be put to good use:
    >
    > You need to declare dest somewhere, and make sure it's at
    > least sizeof(src.ut_name)+1 large.
    >
    > strncpy(dest, src.ut_name, sizeof(src.ut_name));
    > dest[sizeof(src.ut_name)] = '\0';
    >
    > If you also want to use ut_host and ut_line, you have the same issues
    > with them. These fields are not guaranteed to be '\0' terminated
    > and there isn't room to put one there.


    Okay, let me make one more pass at this. Geeze, I almost feel like I'm
    back in 4th grade when I try to post corrected versions of a piece of
    work that I've done. Anyhow....

    #include
    #include
    #include
    #include
    #include
    #include

    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);
    }

    while(read(fd, &log, sizeof(log)) == sizeof(log)){
    strncpy(line, log.ut_name, UT_NAMESIZE);
    line[UT_LINESIZE] = '\0';
    printf("%s\n", line);
    }

    close(fd);
    return 0;
    }

  11. Re: programi parsing question

    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?

    --
    Phlip

  12. Re: programi parsing question

    Phlip wrote:

    > 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);


    AFAIK C cannot define the order those = initializations take. That might be why
    the C literature often shows this antipattern:

    - cram all the variables at the top, uninitialized
    - assign them as they are used
    - fold the assignments together into cluttered lines.

    I improved the pattern by using two initializations that don't care about their
    order. The way to fix excessive initializations is short blocks and short methods...

    --
    Phlip

  13. Re: programi parsing question

    Phlip writes:

    > Phlip wrote:
    >
    >> 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);

    >
    > AFAIK C cannot define the order those = initializations take.


    Not true. Initializers are evaluated in source code order. C99
    6.8 says this:

    The initializers of objects that have automatic storage
    duration, and the variable length array declarators of
    ordinary identifiers with block scope, are evaluated and the
    values are stored in the objects (including storing an
    indeterminate value in objects without an initializer) each
    time the declaration is reached in the order of execution,
    as if it were a statement, and within each declaration in
    the order that declarators appear.

    C89 has similar wording:

    The initializers of objects that have automatic storage
    duration are evaluated and the values are stored in the
    objects in the order their declarators appear in the
    translation unit.
    --
    "I didn't say it was your fault.
    I said I was going to blame it on you."

  14. Re: programi parsing question

    Phlip wrote:
    > Phlip wrote:
    >
    >> 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);

    >
    > 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 ...

    --
    Eric.Sosman@sun.com

  15. Re: programi parsing question

    On Aug 5, 6:54 am, K-mart Cashier wrote:

    > Okay, let me make one more pass at this. Geeze, I almost feel like I'm
    > back in 4th grade when I try to post corrected versions of a piece of
    > work that I've done. Anyhow....
    >
    > #include
    > #include
    > #include
    > #include
    > #include
    > #include
    >
    > 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);
    > }
    >
    > while(read(fd, &log, sizeof(log)) == sizeof(log)){
    > strncpy(line, log.ut_name, UT_NAMESIZE);
    > line[UT_LINESIZE] = '\0';
    > printf("%s\n", line);
    > }
    >
    > close(fd);
    > return 0;
    >
    > }


    Presumably you want all the UT_LINESIZE's to be UT_NAMESIZE, since you
    are looking at log.ut_name.

    But other than that it looks like it should work. Note I still think
    that printf("%.*s",...) is nicer.

  16. 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?
    >
    > --
    > Phlip



    doing something like

    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.

  17. Re: programi parsing question

    On Aug 5, 2:07 pm, fjbl...@yahoo.com wrote:
    > On Aug 5, 6:54 am, K-mart Cashier wrote:
    >
    >
    >
    > > Okay, let me make one more pass at this. Geeze, I almost feel like I'm
    > > back in 4th grade when I try to post corrected versions of a piece of
    > > work that I've done. Anyhow....

    >
    > > #include
    > > #include
    > > #include
    > > #include
    > > #include
    > > #include

    >
    > > 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);
    > > }

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

    >
    > > close(fd);
    > > return 0;

    >
    > > }

    >
    > Presumably you want all the UT_LINESIZE's to be UT_NAMESIZE, since you
    > are looking at log.ut_name.
    >
    > But other than that it looks like it should work. Note I still think
    > that printf("%.*s",...) is nicer.



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

  18. Re: programi parsing question

    K-mart Cashier writes:

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


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


    %.*s prints no more that some number of characters (supplied as an
    argument) and is often used to print character arrays that may not be
    null terminated.

    --
    Ben.

  19. Re: programi parsing question

    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...

  20. Re: programi parsing question

    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?

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