Re: newbie: I/O with nasm

Frank Kotler wrote:
What's the trick to "fgets()"? I tried that, while working up the
"read()" version I just posted, and was getting a segfault. I believe
"fgets()" wants a "FILE *"...

Well it accepts a pointer to an object of type FILE, which is almost
always a structure.
'stdin', 'stdout' and 'stderr' are ISO standard macros which resolve to
these pointers, however from assembly, we'll have to find out their
actual values and pass them instead.

Another "problem" - I was aware of this one - "printf()" doesn't
actually print anything until the buffer is flushed(!). Printing a
newline takes care of it, but if I want to print "name: " and let the
user type his name on the same line? I guess "fflush()" would do it, but
that wants a "FILE *", too!

Yep, we have to find out what stdout resolves to in the implementation
to which we are linking and use the underlying pointer. I admit it is
rather involved and messy.

I actually found the "low level" functions "read()" and "write()" easier
to use! They may not be as "portable", though(?)...

Yes, the less details you have to worry about, the easier. Calling the
C library gives you a lot of useful functions, but, as is demonstrated
by this discussion, it is not without it's attendant complications and
gotchas.

Funny, that the "low level" C calls, dos interrupts, Windows APIs, and
Linux sys_calls are all inherently "safe", but they went and wrapped 'em
in "gets()", which is not.

The beginnings of gets() were back in the 70s when programmers were
supposed to know what they were doing. It turned out to be a nasty
mistake.

As James observes, it won't do any harm to
use it, in this case, but Randy warned me, a long time ago (I think he
was talking to me) that "teaching sloppy solutions to beginners" is a
Bad Idea...

Hence my post, more as a warning to TK rather than James.

As an aside, we could restrict ourselves to using getchar() and read in
one character at a time and fill up a dynamic array, which grows as the
input grows. I easily did this in standard C, since standard functions
like fgets() have length limitations and gets() overwrites data. I
think it is quite straightforward in Assembly as well. We'll be calling
getchar(), and malloc()/realloc(). I'll give it a shot and post the
code in a while here.

.

Relevant Pages

  • Re: fclose(0)
    ... The Standard requires that you pass to fclose a pointer to a stream ... let alone a stream object.) ... No, it isn't, because the Standard doesn't say so. ... type FILE that has a file associated with it. ...
    (comp.lang.c)
  • Re: fclose(0)
    ... The Standard requires that you pass to fclose a pointer to a stream ... of type FILE. ...
    (comp.lang.c)
  • Re: printig effort
    ... and initialize it with the address of the ... *ip is not a pointer. ... *ip is an int. ... It would be if fopenreturned a result of type FILE. ...
    (comp.lang.c)
  • Re: A C++ Whishlist
    ... In the vast majority of member functions the first thing you will do ... If I feel it needs an extra check because it won't crash cleanly I may ... >> unless you also check the this pointer you aren't checking every ... The standard does not say "the this pointer cannot be NULL". ...
    (comp.lang.cpp)
  • Errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie
    ... Today I found out that the official page of errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie is down: ... The first printing of the book was made before the Standard was finalized; these copies say "Based on Draft-Proposed ANSI C" on the front cover. ... ``A pointer may be converted to another pointer whose type is the same except for the addition or removal of qualifiers of the object type to which the pointer refers. ...
    (comp.lang.c)