FILE Access

[Grant Austin]

Hello,

This might be a tad off topic. The c-programming groups
I found appear to be unused...

The problem is simple...

I need to create a listing file from an assembler source file.
The listing file is just a copy of the source file with line numbers
along with a list of syntax errors (e.g. multiply or undefined symbols).

I'm not really sure how to approach this. I figure I can
create an error file and put errors there until the entire source
is processed then copy that into the end of the listing. That doesn't
seem like a great way and I haven't thought of anything better.

Any suggestions are greatly appreciated.

Thanks,
Grant

 

[Ben Pfaff]

I need to create a listing file from an assembler source file.
The listing file is just a copy of the source file with line numbers
along with a list of syntax errors (e.g. multiply or undefined symbols).

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

For your convenience, the list below contains topics that are not
on-topic for comp.lang.c, and suggests newsgroups for you to explore
if you have questions about these topics. Please do observe proper
netiquette before posting to any of these newsgroups. In particular,
you should read the group's charter and FAQ, if any (FAQs are
available from www.faqs.org and other sources). If those fail to
answer your question then you should browse through at least two weeks
of recent articles to make sure that your question has not already
been answered.

* OS-specific questions, such as how to clear the screen,
access the network, list the files in a directory, or read
"piped" output from a subprocess. These questions should be
directed to OS-specific newsgroups, such as
comp.os.ms-windows.programmer.misc, comp.unix.programmer, or
comp.os.linux.development.apps.

* Compiler-specific questions, such as installation issues and
locations of header files. Ask about these in
compiler-specific newsgroups, such as gnu.gcc.help or
comp.os.ms-windows.programmer.misc. Questions about writing
compilers are appropriate in comp.compilers.

* Processor-specific questions, such as questions about
assembly and machine code. x86 questions are appropriate in
comp.lang.asm.x86, embedded system processor questions may
be appropriate in comp.arch.embedded.

* ABI-specific questions, such as how to interface assembly
code to C. These questions are both processor- and
OS-specific and should typically be asked in OS-specific
newsgroups.

* Algorithms, except questions about C implementations of
algorithms. "How do I implement algorithm X in C?" is not a
question about a C implementation of an algorithm, it is a
request for source code. Newsgroups comp.programming and
comp.theory may be appropriate.

* Making C interoperate with other languages. C has no
facilities for such interoperation. These questions should
be directed to system- or compiler-specific newsgroups. C++
has features for interoperating with C, so consider
comp.lang.c++ for such questions.

* The C standard, as opposed to standard C. Questions about
the C standard are best asked in comp.std.c.

* C++. Please do not post or cross-post questions about C++
to comp.lang.c. Ask C++ questions in C++ newsgroups, such
as comp.lang.c++ or comp.lang.c++.moderated.

* Test posts. Please test in a newsgroup meant for testing,
such as alt.test.

news.groups.questions is a good place to ask about the appropriate
newsgroup for a given topic.

 

[Malcolm]

I need to create a listing file from an assembler source file.
The listing file is just a copy of the source file with line numbers
along with a list of syntax errors (e.g. multiply or undefined
symbols).

It's more a programming issue than a C one. C is a reasonable choice of
language to write this program in.
Presumably you already have an assembler. You can evoke it using the
system() function, and direct the output somewhere appropriate (this is
rather platform-specific).
Then you need to run through the assembly listing line by line adding line
numbers and errors. Just call fgets() to read a line, keep a counter going
for the line number, and write a function to change the line into a tagged
line. Presumably the error file contains line numbers and is in numerical
order, so you need to keep track of the topmost error line.

The difficult bit might come if you have several different error formats,
for instance "syntax error line 1" but "line 2, jump label out of range"

 

[Derk Gwen]

# I need to create a listing file from an assembler source file.
# The listing file is just a copy of the source file with line numbers
# along with a list of syntax errors (e.g. multiply or undefined symbols).
#
# I'm not really sure how to approach this. I figure I can
# create an error file and put errors there until the entire source
# is processed then copy that into the end of the listing. That doesn't
# seem like a great way and I haven't thought of anything better.

It's a perfectly satisfactory solution, and the norm for many years. You can
probably use tmpname or its variants to get the file name.

Most modern computers you are likely to use have large virtual memories. It's
likely that you can also store the entire listing in memory, either as a
linked list or a reallocced string (or string array).

Assuming you have enough memory, which you choose is a style question.

 

[Richard Bos]

I need to create a listing file from an assembler source file.
The listing file is just a copy of the source file with line numbers
along with a list of syntax errors (e.g. multiply or undefined symbols).

I'm not really sure how to approach this. I figure I can
create an error file and put errors there until the entire source
is processed then copy that into the end of the listing. That doesn't
seem like a great way and I haven't thought of anything better.

Well, the one thing about this problem that _is_ relevant to C is that,
like most other languages, C doesn't have any features for inserting a
line in the middle of a file, only for appending lines or overwriting,
and perhaps not even the latter for text files.
So if you do want to insert the error message at the first significant
line, then no matter what you do, you will end up reading the file
twice, once to find the errors, once to insert messages about them in
the proper place.

Richard