Date: Mon, 15 Sep 2014 20:35:27 +0200 From: Polytropon <freebsd@edvax.de> To: leeoliveshackelford@surewest.net Cc: Freebsd questions <freebsd-questions@freebsd.org> Subject: Re: Please help with bash, clang, and gdb Message-ID: <20140915203527.482fbc37.freebsd@edvax.de> In-Reply-To: <0a25d1f33a72a97d809538c6d23ee07b@surewest.net> References: <0a25d1f33a72a97d809538c6d23ee07b@surewest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Sep 2014 11:08:19 -0700, leeoliveshackelford@surewest.net wrote:
> I insert the floppy disk, then type as follows:
>
> mount -t msdosfs -w /dev/fd0 /mnt
Note that FAT (the MS-DOS file system) is not able to work
with standard permissions (such as BSD, Unix and Linux).
That's why you should mask the +x attributes on files.
Use this in /etc/fstab:
/dev/fd0 /floppy msdosfs rw,noauto,noatime,-m=644,-M=755 0 0
Then just use
mount /floppy
See "man mount_msdosfs" for details about the flags.
> clang -x c -g /mnt/ProgName.c > mnt/CompOut.txt 2>&1
>
> I do not understand the syntax of the last four characters of the second
> line, but they somehow cause bash to redirect the output of clang
> orginially directed to the monitor screen to the specified file.
The numbers in this quite common construct refer to the
file descriptor numbers: 0 is stdin (standard input,
usually the console keyboard), 1 is stdout (standard output,
usually the console screen), and 2 is stderr (standard error,
usually the console screen as well). What you see here is:
put the standard error messages into standard output,
and redirect both of them into the file CompOut.txt.
Make sure that the result is what you think it is. :-)
Oh, and also note this: FAT does not have case-sensitive
file names (no lowercase or CamelCase), so watch your
file names carefully. It _might_ be that you have to
specify them in UPPERCASE according to the "8.3 convention".
> The
> output file from clang is generated. It contains one warning, and no
> errors. If I then type at the prompt
>
> /root/a.out /mnt/BmIn0001.txt
>
> the a.out program prints to the monitor screen instructions to the user,
> which are followed immediatedly by the prompt symbol. The source-code
> line to open the input file is as follows:
>
> if ((InpFileHand = fopen (argv[1], "rb"))==NULL)
> {
> printf ("nCould not open file %s.", argv [1]);
> exit (11);
> }
According to "man 3 fopen", there is no "b". I know that
this means "binary", but I remember this from writing DOS
programs. On Unix, probably using open() instead of fopen()
is better (as you want to work at character level? See
"man 2 open" and "man 3 fopen" for comparison.
And someone ate the \ infront of the first character 'n'.
Probably that was your webmailer which treats backslashes
as unacceptable characters.\n :-)
Side note: You could use fprintf(stderr, <text>) to signal
an error and print an error message, so your error messages
don't (accidentally) mix with normal program output (and
you can see them even with output redirection). Maybe using
perror() is even better suited because it will look up the
error message text for you; see "man 3 perror" for details.
> The source-code line to open the output file is as follows:
>
> if ((OutpFileHand = fopen (OutpFileName, "wt")) == NULL)
> {
> printf ("nCould not open file %s", OutpFileName);
> fcloseall();
> exit (25);
> }
>
> where OutpFileName is an array of char read from the input file. If I
> enter the following
>
> wait $!
> echo $?
>
> the exit code of 0 is displayed. An exit code of 0 is generated by the
> last line of the program. If the program failed to open either file, an
> error code of either 11 or 25 should have been produced. Even though the
> a.out program exitted normally as far as the operating system is
> concerned, the indicator on the floppy drive never lights, causing me to
> believe that the program failed to read the input file.
Yes, this is a reasonable conclusion. The if-branches are never
entered.
You could rewrite the if block like this, just for testing
and to state clearly what you are doing (example taken from
a DOS program I wrote to deal with the MBR):
mbr = fopen(MBRFILE, "wb");
if(!mbr) {
fprintf(stderr, "fopen()");
exit(1);
}
/* here code for when the file opening was successful */
I admit that the error message isn't very helpful, it should
include the program name, and (most important) the _file name_
that the program was unable to fopen. :-)
This also makes it easy to step through your program with a
debugger.
> When I enter
>
> cd /mnt
> ls
>
> the expected output file is shown to be absent. How did my program get
> all of the way from beginning to end without opening the files, yet not
> exit with expected codes of 11 or 25?
Probably a confusion of == and !=, because it seems to do the
exact opposite of what you think it should be doing. :-)
> Attempting to answer this
> question, I then enter at the prompt
>
> gdb /root/a.out
>
> then, at the gdb prompt, enter
>
> set args /mnt/BmIn0001.txt
>
> gdb fails with an error code of 0177. I research this error code with
> the aid of Google, and am informed that it indicates that, under
> p-threads, the libraries were loaded in an incorrect order. My program
> is intended to be a c language, not c++ language program, with all
> libraries loaded with the executable and linked statically. The only
> libraries referenced in the program are stdio, stdlib, math, and time.
> The only library functions called are printf(), fprintf(), fopen(),
> fcloseall(), fgetc(), ungetc(), fwrite(), sqrtr(), time(), and ctime().
> What do any of these have to do with p-threads?
This might be a preset somewhere.
You can use "truss <yourprogram>" to examine what it tries to
open and what return codes the related functions (!) return,
and which libraries are being loaded at the beginning.
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140915203527.482fbc37.freebsd>