HDTenEightyP/NetNews huggingface dataset:
From: mcsbc2gw@dct.ac.uk
Newsgroups: comp.lang.c
Subject: Re: Pascal to C converter
Date: 6 Nov 92 10:54:17 GMT
Organization: Dundee Institute of Technology

In article <fjoyce.720698844@unix2.tcd.ie>, fjoyce@unix2.tcd.ie (Zeldo the Human Cannonball) writes:
> I was wondering if any has a Pascal to C converter to run on an IBM-PC,
> If anybody has one could they uuencode it and mail it to me, or source
> code would be even more appreciated, C source preferably. 
>
   In reply to the above, I am currently working on a PASCAL to C converter
   program for my own use. If I get it entirely bug free, I will let you 
   know and send you a copy as it will go into the Public Domain.

   I only started it this week, so it maybe a month or two before it is ready!

	In the meantime, why don't youpick up a C programmers reference guide
	and read it. PASCAL is similar to C in many ways and it shouldn't
	take you long to pick it up(The hardest things are passing the
addresses of pointers to a function, but once you've done it it won't be a 
problem!
	
	The C Man

 
>       Thanx in advance.
> Zeldo the Human Cannonball.
> 
> --
> This is a boring .sig
Newsgroups: comp.lang.c
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Subject: Re: EBCDIC to ASCII Conversion
Originator: sasghm@theseus.unx.sas.com
Date: Thu, 5 Nov 1992 20:15:29 GMT
Organization: SAS Institute Inc.


In article <1992Nov5.122240@betsy.gsfc.nasa.gov>, giglio@betsy.gsfc.nasa.gov (Louis Giglio) writes:
|> Does anyone know of a good way to convert EBCDIC characters to ASCII?
|> I have the unfortunate need to transfer binary files from an IBM mainframe
|> to our UNIX machines.
|> 

This question doesn't make sense.  If the files are *binary*, then issue 
of the *character representations* of the two machines/operating systems
doesn't enter the picture.  If the files are *text*, it *does*.

Binary data is binary data.  What it is a *representation* of is
a different issue.

For both types of files we just use ftp. We do this a *lot* for
both text and binary files -- particularly since we now support
a cross-compilation/linking environment on HP/700s for an MVS/CMS
target.  If you want to "roll your own" you need to be careful since
there is no *unique* EBCDIC/ASCII translation.
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: Think this will fly ??
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Wed, 11 Nov 1992 22:56:49 GMT

This is just a repost, i wasn't sure if it made it out. Our line was
down for a few hours,

:  
: Question:
:  
:   I don't know if this has been attempted before, but, would it be 
: possible to label questions and answers for code with the level of
: the person posting it ? 
:  
: It would be nice if we would know if the answer should just be an idea
: for an algorithm, a very basic code outline, actual code, or code
: that also includes an explanation. 
:  
: I like to answer alot of posts, and consequently, don't always give
: every single bit of information about my reply. My assumption usually
: goes something like this:  The code works, is easy to figure out, and
: can be modified if needed. This is also assuming that the person asking
: for the code can FULLY understand any change that is possible.
:  
: If i knew the level (novice, intermediate, advanced) i could respond
: more correctly. I would also label the response with the level it was
: written at. This way a novice would know that an advanced posting 
: isn't the whole answer and wouldn't get stuck assuming it would work
: in all cases as it was posted.
:  
: what do you think ??
:  
: Dave Fuller
: dfuller@portal.hq.videocart.com
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Hows this for odd
Date: 10 Nov 92 22:37:37 GMT
Organization: University of Helsinki

michi@ptcburp.ptcbu.oz.au (Michael Henning) writes:
>	if (strncmp(p, "", 1) != 0) {
[...]
>There are lots of gems like that around :-(

I'm sure there are, but I don't think this is one of them.  It would
IMHO be much worse to leave the explicit comparison off.  This is
because strcmp and strncmp (and other functions with a similar
interface) do not in fact return a value that is conceptually boolean,
therefore doing a boolean operation on it is bad.  Likewise, since an
equality test does not yield a conceptually boolean value, you should
avoid constructs like:

	if ((i==0) + (j==0)) printf("i or j is nonzero\n");

If one is not concentrating (like most people reading code do not seem
to be) the statment

	if (strcmp(foo, bar)) foobar();

looks like it is going to call foobar if foo and bar compare equal,
when in fact the opposite is true.  By making the test explicit,

	if (strcmp(foo, bar) != 0) foobar();

it becomes clearer that strcmp does not return a boolean value.

You are free to disagree about this, of course, and many people
probably do.  It is a completely stylistic issue, and doesn't deserve
a heated discussion.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
From: fizzy@fizzy.ibmpcug.co.uk (Adrian Hall)
Newsgroups: comp.lang.c
Subject: Loadable Binary Modules in Std C
Date: Thu, 12 Nov 92 17:31:38 GMT
Organization: The IBM PC User Group (Staff Network)

A friend and I want to produce a system whereby UPDATES to the system are
sent out as loadable units, so you dont have to stop the system to load in
the update. We have been trying to think of a way to implement this.

The idea is we have a core module (which, amongst other things, would
handle a non-pre-emptive scheduler, memory management, etc.), and the
application modules would then be dynamically loaded as and when required.

Does anyone have any ideas as to how this would be implemented.

Adrian

-- 
+-------------------------------------------------------------------------+
| Adrian Hall                     E-Mail:  adrian@ibmpcug.co.uk   (Inter) |
| Connect Systems Manager		   ..!pipex!ibmpcug!adrian (UUCP) |
| Tel: +44 (0)81 863 1191                Dial-Up BBS - +44 (0)81 863 6646 |
+-------------------------------------------------------------------------+
Newsgroups: comp.lang.c
From: michi@ptcburp.ptcbu.oz.au (Michael Henning)
Subject: Re: How to use 'return' in c?
Organization: Pyramid Technology Corporation
Date: Tue, 10 Nov 1992 03:58:34 GMT

kdq@quest.UUCP (Kevin D. Quitt) writes:

>    On the other hand, since C does not truly support the boolean type,
>I consider it misleading to assign a numeric value to a boolean.  I
>define TRUE as (1==1) because the result of this is a boolean - the
>fact that it is represented by a numerical value is misleading.

No. To be *really* sure you have to use

#define	TRUE	(atoi("1") == atoi("1"))

This is to make sure that the symbolic names and the underlying
representation (2's complement vs 1's complement) are clearly separated.
This enhances portability and makes the code easier to maintain.


					Michi,

					with a :-) for the humour impared.

PS: Kevin, a look at the FAQ would have helped to prevent your posting.
-- 
      -m------- Michael Henning                 +61 75 950255
    ---mmm----- Pyramid Technology              +61 75 722475 FAX
  -----mmmmm--- Research Park, Bond University  michi@ptcburp.ptcbu.oz.au
-------mmmmmmm- Gold Coast, Q 4229, AUSTRALIA   uunet!munnari!ptcburp.oz!michi
Newsgroups: comp.lang.c
From: hansm@cs.kun.nl (Hans Mulder)
Subject: Re: Rounding floats to integers
Organization: University of Nijmegen, The Netherlands
Date: Wed, 11 Nov 1992 16:17:43 GMT

In <BxJx0s.6q8@cck.coventry.ac.uk> champion@cch.coventry.ac.uk (Alun) asks:

>int round(float n)
>{
>    if(n < 0)
>        return (int)(n - 0.5);    
>    return (int)(n + 0.5);     // Doesn't the function do the cast automatically
>}

In C the fact that the function is declared to return an int makes the casts
redundant.  I don't know about C++ (or whatever language it is that you use).
Go and ask in the relevant group, if you really want to know.  Or look it up
in a book.

--
Hope this helps,

Hans Mulder				hansm@cs.kun.nl
Newsgroups: comp.lang.c
From: jonm@Ingres.COM (God is real unless declared integer)
Subject: Re: Hows this for odd
Summary: 
News-Software: VAX/VMS VNEWS 1.4-b1  
Keywords: 
Organization: ASK Computer Systems, Ingres Product Division
Date: 13 Nov 92 14:10:52 GMT

In article <1992Nov9.102217.23060@monu6.cc.monash.edu.au>, bena@yoyo.cc.monash.edu.au (Ben Aveling)        writes...
> 
>Just recently I saw the following fragment of code, and I thought I'd share
>it with you all.  (This is real code, part of a real program people will
>pay money for.)
> 
>	... ,(i==0)?TRUE:FALSE,...
> 
>Am I going mad, or is this slightly redundant ?
> 
Ben,
	Not necessarily so.  What if you have a different definition for
TRUE and FALSE (-1, 0) (or even true=0, false=1).  This would mean a nice
portability filter especially when you start using borrowed code.

If anything you could say... why didn't they just use	

		if (!i)
			...

________________________.   Don't judge a book by your cover...
Jon Machtynger	        |   All opinions expressed above are mine or
jonm@ingres.com	        |   borrowed... do you understand that!  You can
________________________|   just leave the company out of this!

Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: need to create a jump table 
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Sat, 7 Nov 1992 02:15:20 GMT

uyeno@subsys.enet.dec.com (Alice Uyeno) writes:
: 
: Hi,
: 
: I'm trying to develop a jump table.  Actually, the scenario is that I have two jump tables.  Depending on the value of a certain flag, I use one or the other.  Each jump table consists of pointers to functions.  I'm wondering if it is possible to have the functions with varying number of parameters.  For example, if my jump table contains pointers to ErrorRoutine and ValidateCmd, where the prototypes for the routines are as follows:
: 
: 	void ErrorRoutine(int *ErrCode, struct foo * MyPtr);
:         void ValidateCmd(struct foo * CmdPtr);
: 
: void (* FcnTbl[])() = {ErrorRoutine,ValidateCmd};
: 
: where 
: 	ptr = FcnTbl;
: 
: and ptr is how the jump table is referenced.

Alice,
  I would like to help you, but i don't have enough information, also i think
i am slightly confused. you said that you have jump tables (plural), but
i only see a definition for 1 function table. if you really have 2 function
tables then it would be ok to have different # of parameters, but with 1 
table it gets sort of impossible. if it were allowed, you would have to
test the value of the function pointer to know how many parameters to pass.
this is ugly also.

if all of the pointed to functions took the same number of parameters
this would be simple. maybe you need to modify the ideas behind this,
maybe i just dont see well enough into this to solve it.

If you are willing to give more specific info, i'd be glad to try to
help.    

Dave Fuller
dfuller@portal.hq.videocart.com
 
Newsgroups: comp.lang.c
From: kv07@IASTATE.EDU (Warren Vonroeschlaub)
Subject: Re: pixels -> GIF
Reply-To: kv07@IASTATE.EDU (Warren Vonroeschlaub)
Organization: Ministry of Silly Walks
Date: Wed, 11 Nov 1992 22:35:24 GMT

In article <BxIMJx.9w@portal.hq.videocart.com>, dfuller@portal.hq.videocart.com
(Dave Fuller) writes:
>  the GIF file format is not that easy. it includes headers for the
information
> in the rest of the file. (compression mode, color mapping patterns, total
> length of image, graphic x & y sizes, etc . .) these parts MAY be written
> out first, then gone back and rewritten after an fseek, but it's not very
> reliable. any algorithm would probably assume it had the entire image
> available, then try to compress it, then write out ALL of the information
> about the file at once. you could go ahead and write out a default file
> header, not compress the stuff, and then accumulate all of the pixels into
> respective bytes. The process may be easier with the others, i don't know
> anything about them. But i do know the GIF creation won't be that easy
> using the method you are talking about.

  I guess I didn't make myself completely clear.  I have all the information
about the image available to me before hand.  I know the size, and the type.  I
even know exactly what colors will be used and what won't.

  The problem is that resulting image is huge.  I cannot display it all at once,
or load the whole thing into an array.  I can only read one or two rows of
pixels into memory at once, so I have to be able to output them pixel by pixel. 
I can easily do a pass of the data to find any values I might need first.

 |  __L__
-|-  ___  Warren Kurt vonRoeschlaub
 |  | o | kv07@iastate.edu
 |/ `---' Iowa State University
/|   ___  Math Department
 |  |___| 400 Carver Hall
 |  |___| Ames, IA  50011
 J  _____
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
From: rms@miles.com (Rob Schultz)
Subject: Re: Productivity of a C programmer ?
Organization: Miles Inc., Diagnostics Division, Elkhart, IN
Date: Thu, 5 Nov 1992 13:42:25 GMT

In article <Bx753E.5qB@cs.uiuc.edu> marick@cs.uiuc.edu (Brian Marick) writes:
>
>The size of the specification (measured a couple of ways) was poorly
>correlated with time to test and initial coverage.  Lines of code
>(omitting blanks and comments) did slightly better.  Both of them were
>lousy predictors - individual variability and between-program
>variability dominated.


Brian -

Did you by any chance try to correlate this data to Allan Albrecht's
Function Points?  I have been told that this is a very good method of
predicting (non-embedded) software development/testing effort, as well
as a good bug predictor.

thanks -
     rms

-- 
Rob Schultz   At Home:                        At work:          +1 219 262 7206
                      rms@andria.miles.com                        rms@miles.com
      {uunet|iuvax}!gator!miles!andria!rms        {uunet|iuvax}!gator!miles!rms
Newsgroups: comp.lang.c
From: aa@rexago8.uucp (Adam Andrews)
Subject: Re: To Recurse or NOT to recurse?
Organization: Summit Information Systems
Date: Sun, 8 Nov 1992 22:04:48 GMT

dfuller@portal.hq.videocart.com (Dave Fuller) writes:
>sjs@netcom.com (Stephen Schow) writes:
>: ... SHould I use recursion
>: to search down through the list for the last node, or should I use a while
>: loop?  What or the pro's and con's of each?
>
>Recursion would, however, be the choice if you need to do an operation that
>needs to keep a state constant. Menuing functions are good examples of this.
> 
>although there probably are exceptions, the only good time for recursion
>is when code will be reused and needs to keep each state of its instance
>completely independant of the others.

Another good use of recursion is the traversal of a tree structure, as 
opposed to a linked list.


-- 
Adam Andrews                "When the going gets weird, we get even weirder."
uunet!rexago8!aa or aa@rexago8.UUCP       e-mail only to aa@summitis.com
Newsgroups: comp.lang.c
From: root@berta.bln.sni.de (0000-Admin(0000))
Subject: Re: Two-dimensional Array
Organization: Siemens Nixdorf Informationssysteme AG, Berlin, Germany
Date: Tue, 10 Nov 1992 08:56:32 GMT

niu@prancer.eche.ualberta.ca (Shaohua Niu) writes:

>I am trying to use dynamic memory allocation for two-dimesional
>matrices and the code fragment is as follows:

>typedef float **MATRIX;

>MATRIX calloc_matrix(int row, int col)
>{
>  int i;
>  MATRIX mat;
>  mat = calloc(row, sizeof(float *));
>  if (mat==NULL) exit(1);
>  for (i=0; i<row; i++) {
>	mat[i] = calloc(col, sizeof(MATRIX));
>	if (mat[i]==NULL) exit(1);
>  }
>   return mat;
>}

>when this is called with row=9 and col=9, the fucntion works for the
>pointer mat[0] to mat[6], but for mat[7], it exited abnormally to DOS,
>with an error message saying memory allocation error, and the DOS

If you want to allocate 2-dim Arrays, then all elemnts of the array have to
been alloacte in subsequent memory locations. A Pointer to the first Elemnt of
a two dim Array is not equivalent to a pointer to pointer.

i.e.
double matrice[10][5];

matrice is of datatype double (*)[5]. An all 50 Elemnts of the Array are allocated
beginning at that location. so better do:
typedef void *MATRIX;

MATRIX calloc_matrix(int row, int col)
{
  int i;
  MATRIX mat;
  mat = calloc(row*col, sizeof(float));
  if (mat==NULL) exit(1);
   else
   return mat;
}

Use of mat:

main()
{
	float		(*mat1)[5]; /* pointer to 1st Element of mat */
   mat1=calloc_matrix(10,5);

	mat1[1][3]=1.2;
	mat1[5][4]=1.3;
	:
	:
}
Lars Eisenblatt
usually lars@pfm.rmt.sub.org
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: GCC libraries (was GCC and all that)
Date: 6 Nov 1992 11:26:50 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Distribution: world
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <alien.00qf@acheron.amigans.gen.nz> alien@acheron.amigans.gen.nz
(Ross Smith) writes:
>... This library code is, of course, covered by the FSF's licence
>(the library licence is slightly different from the application licence,
>but in this context the result is the same), and, therefore, so is the
>resulting executable.

There is some question as to whether part or all of the libraries
included as an integral part of GCC `force' code redistribution a la
the usual (GPL) license.  Regardless, however, there is an alternative.
The HP300 and SPARCstation ports of 4.4BSD both use GCC as the
standard compiler; however, the entire C libraries of both ports
are covered only by the usual Berkeley license, occasionally augmented
with author names and/or LBL credit requirements.

This includes my replacement for the `long long' library used to do
64-bit operations on 32-bit CPUs.  Mine should be considerably more
efficient than the one FSF version I saw (which may well have been
replaced since then).  We decided it was safest to rewrite, rather than
depend on one particular interpretation of the `gnulib' license text,
and I was appalled at the idea of adding 64-bit quantities 16 bits at
a time. :-)

Note that a few of the primitives are necessarily written in assembly,
or make heavy use of asm() inlines (which amounts to the same thing),
and are therefore not portable.  The majority of the code is either
fully portable or includes `nearly portable' C implementations (such
as the C version of bcopy/memcpy/memmove).

>In theory, I could get around this by writing my own linker libraries; in
>practice, I'm not wizard enough for that to be a realistic alternative.

So, get the net.2 and/or 4.4BSD distributions. :-)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.lang.c
From: rons@hardy.u.washington.edu (Ronald Schoenberg)
Subject: Re: Reasons for using C vs. Fortran or vice/versa
Organization: University of Washington, Seattle
Distribution: usa
Date: Thu, 12 Nov 1992 20:58:23 GMT

In article <1992Nov12.135901.15191@ccd.harris.com> djulian@controls.ccd.harris.com (Danny E. Julian) writes:
>Hello,                  
>
>This may or may not be the place to ask this, but here I go anyway.
>
>I was wondering what advantages Fortran has over C(if any) and vice-versa.
>
>I know C is much better than Fortran in the I/O dept., but is there anything
>else that makes it a better language.
>
>The reason I ask is when was in college, we used C for our primary language.
>But the company I work for, uses a lot of Fortran(mainly because it was
>written years ago and still works).  We do a lot of number crunching around
>here and I've always been told that Fortran was very good at that.
>
>Is Fortran actually better than C for number crunching routines?
>

Yes.  For example, try passing a pointer of a two-dimensional array
with arbitrary dimensions as an argument in a function in C.  Fortran
is faster on the big machines because they've been working on the
optimization for a long time.  Fortran arrays are column echelon for a
reason, and C arrays are row echelon slowing down matrix operations
relative to Fortran.
 
But speed isn't everything.  Productivity is also important and there
C++ has it all over either C or Fortran.  I do a lot of
number-crunching programming and I use the M++ class library which
essentially turns C++ into an array language - it'll do all Fortran 90
will do and you have C++ as well.  It is a little slower than Fortran,
though, but the gains in productivity are huge.

Best would be to do it in C++ (forget C - you get the worst of both
worlds, slower code and slowest productivity), get some matrix
classes, and wrap your Fortran in C++ function calls.  The C++ then
essentially becomes an interface to your Fortran, making it much
easier to use because all those tedious Fortran function arguments are
handled by the matrix classes.

Ron Schoenberg
From: rons@hardy.u.washington.edu (Ronald Schoenberg)
Newsgroups: comp.lang.c
Subject: Re: Reasons for using C vs. Fortran or vice/versa
Date: 13 Nov 92 06:07:01 GMT
Article-I.D.: u.1992Nov13.060701.6917
Distribution: usa
Organization: University of Washington, Seattle

In article <gay.721614205@sfu.ca> gay@selkirk.sfu.ca (Ian D. Gay) writes:
>rons@hardy.u.washington.edu (Ronald Schoenberg) writes:
>
>>  Fortran arrays are column echelon for a
>>reason, and C arrays are row echelon slowing down matrix operations
>>relative to Fortran.     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Maybe I'm missing something, but I don't see why this should be so. 
>Could you explain more fully?
>
>
>>Ron Schoenberg

The most important matrix operation in numerical work is the gaxpy
("generalized a times x plus y").  Numerical routines are written to
be rich in gaxpies (see Matrix Computations by Golub and Van Loan for
details). In the source code below I have written two gaxpies, one
for data stored column echelon and a second for the same data stored
row echelon.  The only difference between the two is in the
calculation of the index of the element of the two dimensional array
used in the multiplication.  You will note that the index in the
column echelon storage is a simple increment, whereas in the row
echelon storage two operations in addition to the assignment are 
required.  I know very little about assembly code, but I believe that an
assembly version of the column echelon gaxpy is especially efficient,
while the assembly code for row echelon would involve a number of extra
operations.

As I'm sure you well know, if you were to actually use the two
dimensional arrays in C (I avoid it myself), the generated 
assembly code would contain the extra operations because data in
two-dimensional C arrays are row echelon.  C programmers have
dispensed with one additional operation by using the zero offset.
But for really efficient numerical work that is not enough.

Actually I program in C++ using the M++ matrix class library.  
M++ is based on the BLAS (Basic Linear Algebra Subroutines) which are
most efficient when data are stored column echelon, and therefore
M++ stores its data column echelon.  But I don't have
to think very much about how the data are stored because that is all
taken care of for me behind the scenes (viva la C++).

I apologize for any faux pas in the code below - I am a converted
Fortran number-cruncher.


#include <stdio.h>

void main()
{
    float a_col[] = { 1,5,9,13,2,6,10,14,3,7,11,15,4,8,12,16 };
    float a_row[] = { 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 };
    float x[] = { 1,2,3,4 };
    float z[4];

    int m = 4, n = 4;
    int i, j, k;

/*
** column echelon gaxpy
*/
    for (i = 0; i < m; i++) {
        z[i] = 0;
        k = i;
        for (j = 0; j < n; j++) {
            z[i] += a_col[k] * x[j];
            k += n;
        }
    }

/*
** row echelon gaxpy
*/
    for (i = 0; i < m; i++) {  
        z[i] = 0;
        for (j = 0; j < n; j++) {
            k = i * n + j;
            z[i] += a_row[k] * x[j];
        }
    }
}
Newsgroups: comp.lang.c