Garance_Drosehn@mts.rpi.edu (04/05/91)
Time for a few programming questions!
I'm trying to port some C code to my friendly NeXTStation (400meg drive). I'm
not much of a C or Unix wizard, so these questions might have obvious
answers...
1) Is there some manual or set of manuals for programming the Next, or should
I just look thru all the digital-library documents?
2) What I'm working on includes a library of subroutines. I can compile them
OK, but what commands do I need to turn them into a subroutine library? (ie,
a "libXXX.a" file)
3) I tried to come up with the magic parameters to the "ld" command to load
all my C object files into a runnable application. I tried
ld -o my.app ${OBJECTS} -lsys_s -crt0.o
but that was just guesswork and not suprisingly it didn't work very well.
The program loads fine but dies when I try to run it (with "memory access
exception in NXZoneCalloc", presumably something in the environment isn't
setup right).
I then took (what I consider) the sleazy way out and used:
cc -o my.app ${OBJECTS}
which works fine. What parameters is cc sending on to ld? I have CFLAGS
set to "-ansi -pendantic -g -Wimplicit", if that's of any interest. It's
a quirk of mine that I feel silly using the compiler when I'm not actually
compiling anything at that step.
4) Once I got past the loader, the program basically works. One odd thing
(compared to what I've seen on other platforms) is that the fprintf
subroutine seems to always return a value of zero. Ie, a statement of:
PLen += fprintf(fp, "%d", Num);
will always add zero to PLen. On the other platforms that I've tried
these routines on so far, fprintf returns the number of bytes it just
printed. Is there something I'm missing here.
I can get around this by using the %n conversion character, eg:
fprintf(fp, "%d%n", Num, &Temp_Int);
PLen += Temp_Int;
but that makes it two statements instead of one, and looks kinda stupid
anyway. Is there some way I could make fprintf work the way I'm expecting
it to?
Well, that's all the questions I remember at the moment. Send any and all
suggestions to Garance_Drosehn@mts.rpi.edu (or gad@eclipse.its.rpi.edu) and I'd
appreciate it. I'm not sure if comp.sys.next itself is a good place for long
threads on programming suggestions...
- - -
Garance_Drosehn@mts.rpi.edu
or gad@eclipse.its.rpi.edu (NeXT mail)eps@toaster.SFSU.EDU (Eric P. Scott) (04/05/91)
In article <h4+gjkn@rpi.edu> gad@eclipse.its.rpi.edu writes: >1) Is there some manual or set of manuals for programming the Next, or should > I just look thru all the digital-library documents? Except for some of the hardcopy material shipped with every system, all of the documentation is either available online as part of the "Extended" (i.e. non-Crippled) release which you have, or via anonymous FTP from various archive sites. The NeXT documents basically cover the differences/extensions from 4.3 BSD. If you're using the NeXT as a "plain UNIX box" there are plenty of references on BSD UNIX for all levels of expertise. Find something you like. >2) What I'm working on includes a library of subroutines. I can compile them > OK, but what commands do I need to turn them into a subroutine library? (ie, > a "libXXX.a" file) ar ranlib >3) I tried to come up with the magic parameters to the "ld" command to load > all my C object files into a runnable application. I tried > ld -o my.app ${OBJECTS} -lsys_s -crt0.o > but that was just guesswork and not suprisingly it didn't work very well. Not surprisingly. > I then took (what I consider) the sleazy way out and used: > cc -o my.app ${OBJECTS} > which works fine. Right. > It's > a quirk of mine that I feel silly using the compiler when I'm not actually > compiling anything at that step. Too bad. That's what's portable. ld is subtly different on just about every UNIX variant. Get out of the habit of using it directly. >4) Once I got past the loader, the program basically works. One odd thing > (compared to what I've seen on other platforms) is that the fprintf > subroutine seems to always return a value of zero. Different UNIX implementations disagree here. This is just something you'll have to live with. You're the first person I've seen who actually cared--usually the question comes up with respect to sprintf. > Is there some way I could make fprintf work the way I'm expecting > it to? Not really. I primarily write two kinds of code: 1) "Don't kid yourself; this will never, ever run on anything but a NeXT." 2) Intended to run on as many different UNIX dialects as possible. If (2) is reasonable, (2) is invariably the most useful, even if it means lots of #ifdefs. I don't write a lot of (1). I use cc -bsd heavily. -=EPS=-
jwright@cfht.hawaii.edu (Jim Wright) (04/05/91)
eps@toaster.SFSU.EDU (Eric P. Scott) writes: >In article <h4+gjkn@rpi.edu> gad@eclipse.its.rpi.edu writes: >> the fprintf subroutine seems to always return a value of zero. >Different UNIX implementations disagree here. This is just >something you'll have to live with. You're the first person >I've seen who actually cared--usually the question comes up >with respect to sprintf. I can find no NeXT documentation on what the printf family returns. I know the agony of porting code that uses these return values, but that's no reason not to document them. Nothing in digital librarian. grep turned up only: stdio.h:extern int fprintf(FILE *stream, const char *format, ...); -- Jim Wright jwright@cfht.hawaii.edu Canada-France-Hawaii Telescope Corp.
Garance_Drosehn@mts.rpi.edu (04/07/91)
In article <h4+gjkn@rpi.edu> Garance_Drosehn@mts.rpi.edu (that's me...) writes: >Time for a few programming questions! And now I'll summarize all the answers I got. >1) Is there some manual or set of manuals for programming the Next, or should > I just look thru all the digital-library documents? The answer here seems to be "b", just look thru all the online documentation. >2) What I'm working on includes a library of subroutines. I can compile them > OK, but what commands do I need to turn them into a subroutine library? check "ar" and "ranlib" in the man pages. >3) I tried to come up with the magic parameters to the "ld" command to load > all my C object files into a runnable application. (...skipping along...) > I then took (what I consider) the sleazy way out and used: > cc -o my.app ${OBJECTS} The unanimous answer here was that using "cc" was the correct way to do what I wanted. My experience from some other (non-Unix) systems was simply leading me down the wrong path. >4) Once I got past the loader, the program basically works. One odd thing > (compared to what I've seen on other platforms) is that the fprintf > subroutine seems to always return a value of zero. (...etc...) The concensus was that I'd be smarter not to use the return value from fprintf anyway, because fprintf returns different things on different systems. While I have nothing but thanks for the other three answers, I'd like to quibble about this answer a bit. I'll do that in a separate thread though. Garance_Drosehn@mts.rpi.edu or gad@eclipse.its.rpi.edu
rca@cs.brown.edu (Ronald C.F. Antony) (04/09/91)
In article <jwright.670841680@cfht.hawaii.edu> jwright@cfht.hawaii.edu (Jim Wright) writes: >eps@toaster.SFSU.EDU (Eric P. Scott) writes: >>In article <h4+gjkn@rpi.edu> gad@eclipse.its.rpi.edu writes: >>> the fprintf subroutine seems to always return a value of zero. > >>Different UNIX implementations disagree here. This is just >>something you'll have to live with. You're the first person >>I've seen who actually cared--usually the question comes up >>with respect to sprintf. > >I can find no NeXT documentation on what the printf family returns. I know >the agony of porting code that uses these return values, but that's no >reason not to document them. Nothing in digital librarian. grep turned >up only: > >stdio.h:extern int fprintf(FILE *stream, const char *format, ...); Good advice here: For UNIX questions look in the MAN PAGES, and NOT in the NeXT Developer Docs. If you are interested further in this topic, have a look at the vprintf, vfprintf and vsprintf functions and their MAN PAGE entry. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet
jwright@cfht.hawaii.edu (Jim Wright) (04/11/91)
rca@cs.brown.edu (Ronald C.F. Antony) writes: > jwright@cfht.hawaii.edu (Jim Wright) writes: > > [no mention of return value for fprintf in digital librarian] > For UNIX questions look in the MAN PAGES, and NOT in the NeXT > Developer Docs. > If you are interested further in this topic, have a look at the > vprintf, vfprintf and vsprintf functions and their MAN PAGE entry. I have the unix man pages included in digital librarian. Isn't this the default? So yes, thank you, I did RTFM. Still no answer as to what NeXT thinks the return value is. -- Jim Wright jwright@cfht.hawaii.edu Canada-France-Hawaii Telescope Corp.
Garance_Drosehn@mts.rpi.edu (04/11/91)
In article <jwright.671358522@cfht.hawaii.edu> jwright@cfht.hawaii.edu (Jim Wright) writes: >rca@cs.brown.edu (Ronald C.F. Antony) writes: > jwright@cfht.hawaii.edu (Jim Wright) writes: jim1> [no mention of return value for fprintf in digital librarian] > ron1> For UNIX questions look in the MAN PAGES, and NOT in the NeXT ron1> Developer Docs. ron1> If you are interested further in this topic, have a look at the ron1> vprintf, vfprintf and vsprintf functions and their MAN PAGE entry. > jim2>I have the unix man pages included in digital librarian. Isn't this jim2>the default? So yes, thank you, I did RTFM. > jim2>Still no answer as to what NeXT thinks the return value is. As the guy who started this question (even though I'm not in the above exchange), thanks to Ron for pointing me in the right direction. I still would prefer that all C functions on the NeXT followed the ANSI C standard definition for them, of course, but at least there was an answer buried in the man pages. And for Ron: the man page for fprintf doesn't give the answer, but if you use the digital librarian to search the man pages for "fprintf" you'll also get a match on a "stdio" man page. That explains the return values. What it says is: An integer constant EOF (-1) is returned upon end-of-file or error by integer functions [in the STDIO set] that deal with streams. Of course, that doesn't mean the functions are required to return zero if there is no error. Not sure how much code would depend on the "EOF or nothing" (so to speak :-) return value for fprintf & friends (especially since the ANSI standard defines a different return value), but I imagine some code might. Sigh. Just proves the old adage, I guess: "The nice thing about standards is that there are so many to choose from"... Garance_Drosehn@mts.rpi.edu = gad@eclipse.its.rpi.edu for Next-Mail
eps@toaster.SFSU.EDU (Eric P. Scott) (04/12/91)
One more time... The C libraries provided by NeXT are primarily based on 4.3 BSD. They are not ANSI libraries, they are not GNU libraries. They are (old) BSD libraries. All the things you're griping about are straight from AT&T. I'm not convinced that "ANSI" C is a good thing (last I heard it *wasn't* a standard either, only a draft standard). It could be worse... "POSIX compilance" is the WORST disease to ever afflict the UNIX community (yes, Virginia, worse than X). [Let's not start a flame war on this, guys...] -=EPS=-